Shrink system identifiers

[GoogleCodeExporter]

Is it possible for packer to shrink system identifiers, like "window" and 
"document.getElementById"? I see a lot of code that manually adds shortcut 
variables, like this;

    var w = window, d = document, id = document.getElementsById;
    //...

This type of code doesn't help the understandability of the code, and should 
be done by tools.

Original issue reported on code.google.com by doek...@gmail.com on 29 Aug 2009 at 10:05

[GoogleCodeExporter]

That's doable. I've even already written the code to do it. There is only one 
problem. 
The code *must* run in a closure or the global namespace will become polluted. 
There 
are also concerns for performance but maybe I got my initial testing wrong.

Original comment by dean.edw...@gmail.com on 29 Aug 2009 at 11:14

[GoogleCodeExporter]

I didn't think of the closure issue. But couldn't it be solved by this:

    function() {
        var w = window, d = document, id = document.getElementsById;
        with (w) {
          ...
        }
    }

(just quick thinking, not sure if it works)

About performance: I would expect it to be faster, at least with static method 
abbreviation (id = 
document.getElementsById), since you don't need a member lookup.

Original comment by doek...@gmail.com on 30 Aug 2009 at 8:35

[GoogleCodeExporter]

Yes, I could wrap it in a closure but then id the script itself creates global 
variables then they 
will no longer be visible to other scripts.

Regarding performance, I'm pretty sure that an id function must be bound to a 
document for it to work. 
But I was think more like this:

var d = document, g = "getElementById";

var element = d[g]("#example");

Basically, I can build a dictionary of method names and store them. I need to 
do some performance 
testing. I think the overhead comes from having a dictionary with nested 
closures. I've already 
written the code to build the dictionary. If I send it to you do you want to 
check out the 
performance. I think it was MSIE (of course) that suffered.

Original comment by dean.edw...@gmail.com on 30 Aug 2009 at 8:46

[GoogleCodeExporter]

I could check out the performance. Do you have a test page for this? I can test 
for OS X 
now, but windows testing (MSIE) has to wait a couple of weeks.

Original comment by doek...@gmail.com on 30 Aug 2009 at 9:07

[GoogleCodeExporter]

I'll have to prepare something. But I can wait a couple of weeks. Windows 
testing is 
the most important.

Original comment by dean.edw...@gmail.com on 30 Aug 2009 at 11:32

[GoogleCodeExporter]

I can test Windows now.

Original comment by doek...@gmail.com on 22 Sep 2009 at 11:45

[GoogleCodeExporter]

I take it all Base2 code is wrapped in a closure anyway right? I might be 
saying something stupid here but why 
not do the following:

(function (nativeWindow, nativeDocument, nativeGetElementById)
{

  // Now packer will shrink those for us but the code will still be readable

  nativeWindow.alert(nativeDocument);

})(window, document, document.getElementById)

Original comment by marijn.huizendveld@gmail.com on 24 Nov 2009 at 9:28

[GoogleCodeExporter]

I've added a little functionality to support this. Not much though. ;)

I don't think that too many people are concerned about compressing packages 
100% efficiently. 
I've added some functionality that means that core base2 packages will compress 
more effectively 
(although it's not hugely noticeable after gzip).

For those people using the current php build system for your packages (probably 
not too many of 
you), then there are some changes to the way the package.xml files are 
structured. But hopefully 
you won't notice any changes. If you have any problems then post to the 
base2-js google group.

The old way of building packages using "eval(this.exports)" is now deprecated. 
It still works but 
I've added a new export mechanism which is more friendly regarding compression.

Old way:

new function() {
  var shapes = new base2.Package(this, {
    name: "shapes",
    version: "1.0",
    exports: "PI,Shape,Circle,Rect", // DEPRECATED
  });

  eval(this.imports);

  var PI = 3.14;

  var Shape = Base.extend({
    ...
  });

  var Circle = Shape.extend({
    ...
  });

  var Rect = Shape.extend({
    ...
  });

  eval(this.exports); // DEPRECATED
};

New way:

new function() {
  var shapes = new base2.Package(this, {
    name: "shapes",
    version: "2.0",
  });

  eval(this.imports);

  var PI = 3.14;

  var Shape = Base.extend({
    ...
  });

  var Circle = Shape.extend({
    ...
  });

  var Rect = Shape.extend({
    ...
  });

  this.exportSymbols({  // <== Use this instead
    PI: PI,
    Shape: Shape,
    Circle: Circle,
    Rect: Rect
  });
};

I prefer the symmetry of the old way but the new way leads to slightly better 
compression and 
more obfuscated code. The old way will still work though. :)

These changes will be in the next check-in to /trunk/lib/. The version number 
will be 
"1.1(alpha4)".

If you don't like these changes then it is not too late to say so. :)

Original comment by dean.edw...@gmail.com on 14 Dec 2009 at 9:42

• Changed state: started

[GoogleCodeExporter]

Hmmm, personally I prefer the old API but this will probably yield more 
favorable compression. Looking forward 
to the code:)

Original comment by marijn.huizendveld@gmail.com on 16 Dec 2009 at 9:56

[GoogleCodeExporter]

The old API will still be there. I doubt that I'll ever remove it.

TBH, after gzip, the savings aren't significant. But all code is different so 
please 
share your findings.

I've found a bit of spare time to work on base2 so I may check something in 
pretty 
soon.

Original comment by dean.edw...@gmail.com on 16 Dec 2009 at 10:27

[GoogleCodeExporter]

This simple request has made me realise that there is quite a serious bug in 
the current 
packaging system.

Basically, eval(this.exports) does not work correctly once a script has been 
minimised 
(variables renamed). See issue #126.

This is a serious enough bug that I've had to rewrite the packaging system.

I'll post a detailed description of the new Packaging system on the mailing 
list (it's not 
very different).

In the meantime, I am closing this issue.

Original comment by dean.edw...@gmail.com on 5 Jan 2010 at 2:05

• Changed state: WontFix