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:

 String.<capitalized constant name>

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

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

One non-trivial achievement for JavaScript. And a good thing for the wwww1. 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 contants2. 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:

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)”

Comments are closed.