dbj( org ); Valuable savings (a.k.a. String constants)

Has any one thought of this before ? I actually think this is a “good thing”.

Here I am talking about JavaScript as a stand alone programming language. Not about browser+JavaScript.

String constants. This is the feature, I would like to have (in the JavaScript language) :

// in-built properties of the String object

String.empty // defined as : ""

String.space // " "

String.F // "function"

String.U // "undefined"

String.O // "object"

String.S // "string"

String.N // "number"

String.NL // "\n" ... "\r" in IE

String.T // "\t";

String.R // "\r";

// and so on ...

Now imagine the space savings if You use this everywhere in your code ? Sizeable, but not dramatic.
And now imagine the savings if this is part of the ECMA 5?
Now, that just might be something we might call: “valuable savings” … The more we use it, the more we save.

Also.If this is part of the language (ECMA5) all of the string literals, lurking around JavaScript , should be made into an:

1	String.<capitalized constant name>

With the added benefit of them actually being constants. And yes, including this one too :

1	String.strict ; // defined as "use strict"

One non-trivial achievement for JavaScript. And a good thing for the wwww¹. If this is made part of ECMA5, then everyone will be using this everywhere. Thus, the total size of HTTP traffic on the www will be measurably smaller. Is this just my speculation? I dare to think, not.

Update 2009 08 12

String literals are bad. Not having constants in a language is bad. Having string literals and no constants, is even worse. What are the constants for is well known. Imagine if Math.PI would not be a constant ? VBScript has contants². String literals are always gouped in “one place” . Other platforms (.net, java) have resource files where string dictionaries are kept . Transforming “official” string literals into string constants, it the least we can do for the JavaScript. Especially these days when it tryes to grow-up with the help of ECMA comitee.

Update 2009 08 13

Jacke Archibald “made me” add this important clarification.
Before minimization there are no savings. After minimaztion, in the presence of global constants there are sizeable savings. String literlas can not be compressed, while a constant String.jacke // defined as: "Jacke Archibald" ; can be effectively compressed . This is also yet another convincing example on why string literals are bad.

Update 2009 08 14

I can present an workable solution for this straight away. I have found this interesting “compressor” here: http://www.xtreeme.com/cgi-bin/js-optimizer/js-optimizer.cgi. It has an interesting (and unique?) feature of understandning #define commands. Example :

#define String.empty ""

function F () { var a = String.empty , c = String.empty ,b = String.empty ; }

Is transformed into:

1	function F(){ var a="",c="",b=""; }

There are other commands like #if #else #endif etc . Of course #defines are hidden in /* */ comments. This compressor seems an ideal candidate to implement String constants support, before ECMA comitee does:

// GPL (c) by DBJ.ORG(tm)

// if not part of your JavaScript

// add these String constants first (before anything else)

String.empty = ""

String.space = " "

String.F = "function"

String.U = "undefined"

String.O = "object"

String.S = "string"

String.N = "number"

String.NL = "\n"

String.T = "\t";

String.R = "\r";

// and so on ...

// now define a global array that will reference the constants and that will be used by #defines

// \u1234 as a global JavaScript name, is very unlikely to clash with anything else

\u1234; = [ String.empty, String.space, String.F, String.U, String.O , .... ] ;

// now #defines for compressor

#define String.empty \u1234[0]

#define String.space \u1234[1]

#define String.F \u1234[2]

#define String.U \u1234[3]

... and so on for all the other constants

The rest of the code, now can use String constants for improved maintainability, changeability and less bugs.

function F () {

var a = String.empty , c = String.F ,b = String.U ;

}

// add hundreds of kilobytes of JavaScript source here, all using the mechanism above

After the transformation through the “compression”, the result is :

// we need this until String constants are part of the language.

String.empty=""

String.space=" "

String.F="function"

String.U="undefined"

String.O="object"

String.S="string"

String.N="number"

String.NL="\n"

String.T="\t"

String.R="\r"

\u1234;=[ String.empty,String.space,String.F,String.U,String.O,.... ]

function F(){

var a=\u1234[0], c=\u1234[2], b=\u1234[3]

}

//NOTE: Yes, this is legal JavaScript

Above will work and will bring all the benefits of String properties (and other) as global constants. Until we have ECMA Script which has these constants built in.
After which event, we do the same compression technique, without our global constants. Looks a (bit too) complicated. For large javascript web applications this would be a very important feature to improve the code quality and app stability. With the help of the (ever important) code compression. Also, after global constants are part of the language, compressors can use the same technique, but transparently to the users.

^{1: “whole www” a.k.a. “wwww”

2: There are JavaScript “solutions” which are using VBScript to “implement” constants in IE+JScript.}

11 thoughts on “Valuable savings (a.k.a. String constants)”

Andrea Giammarchi
2009-08-10, 16:55

when you have to write String.empty rather than “”, to discover in whatever nested scope the String up to the global scope, and finally to use dynamic public properties rather than statically “compiled” strings, what exactly are you saving?
- Dusan
  2009-08-10, 17:06
  
  Space?
  
  Less bugs?
  
  Also. This means introduction of (at last!) string constants into the language. Etc …
Andrea Giammarchi
2009-08-10, 20:00

Introduction to string constants? I define global scalar constants in almost every browser since October 2007:
http://webreflection.blogspot.com/2007/10/cow-javascript-define-php-like-function.html

Regards
Marijn Haverbeke
2009-08-13, 08:50

Your proposed feature sounds like something a JS implementation could very easily do ‘in the background’ (probably some of them are already
doing it for things like “string”, “number”), and not something you’d want to bother programmers with anyway (‘var name = String.empty’? Ewww.)

Best,
Marijn
Dusan
2009-08-13, 08:53

Well that is the point exactly. If it is so obviously easy and usefull why not just have it in the language? Ohter languages are doing it too (C#: string.empty).

String literals are bad.

First thing with which I keep in suspense young colegues, is to ask them to write code where there is no string literals at all. In any prog. language. So yes, they are “bothered”. Especially after they realise what is good about not having string literals : Code becomes more manageable and maintainable. Which in turn elevates programers productivity.

–DBJ
Jake Archibald
2009-08-13, 11:58

It could be that I’m missing something, but where’s the space saving using String.S instead of “string”, I count the same chars. In the case of String.T, that’s larger than “\t”.

I’m not against string constants, but they’d need to be named differently. String.T doesn’t mean ‘\t’ to me, and why does String.T mean ‘\t’ while String.N doesn’t mean ‘\n’?
Dusan
2009-08-13, 12:15

@Jake
Savings: before mini-mization|fication there are no savings. After it there are sizeable savings. String literlas can not be compressed, while String.jacke // defined as: “Jacke Archibald” ; can be compressed as any other var name. This is a good question, and I should have had it in original posting.
Naming: lets leave it to ECMA comitee. Or not, they are known on not being able to agree easily between themselves ;o)

–DBJ
Jake Archibald
2009-08-13, 12:23

There’s only a saving after minification if String.WHATEVER is aliased to a non-global variable. Once it’s aliased to a non-global variable, yes, a minifier will try to compress it down to a single char. So yeah, you’d save space if you did…

1
2
3
4

(function(){
  var emptyStr = String.EMPTY;
  // more code
})();

But, you’d save even more space if you did

1
2
3
4

(function(){
  var emptyStr = '';
  // more code
})();

Minifiers (as far as I’m aware) cannot compress property names, or global variables.

Marijn Haverbeke
2009-08-13, 14:20

That’s not going to work, someone can do window[“my” + “var” + “name”], and
I’ve actually seen scripts that do things like that. All proper
minifiers seem to just leave globals (and object property names) as
is.

I’m starting to doubt the utility of minifying in general. Just serve
your scripts gzipped.
Marijn Haverbeke
2009-08-13, 14:37

(Ah, you were talking about constants, not globals. Still, how often do you expect these to repeat themselves? Humanity has challenges that are more interesting than getting a few bytes off a JavaScript file. Also, you’d make constant access slower.)