🚀 go-pugleaf

Time for my two cents...

As it stands right now, I have three methods added to Array (contains, indexOf, 
lastIndexOf) so that it has an interface that matches String more closely.

On String, I've added 8 or so methods (like contains, trim, and startsWith) for 
stuff that I typically need to do with Strings.

For C-printf-style formatting, I've added String:sprintf, Date:strftime, and 
File:strf.

On Folder, I've added my own implementation of getFiles (the original 
implementation had bugs and didn't support RegExp matching) and some similar 
methods (for doing recursive getFiles calls, for instance).


I have stayed away from extending PS/JS-DOM or ID/JS-DOM classes because not all 
classes have bindings to the interpreter at startup.

While Dirks technique
    app.activeDocument.pages;
    Pages.prototype.fancy = function ()
    {
        $.writeln(this.length);
    }

works fine if there is a open document, it doesn't work in the general case, so 
I can't write a set of extensions, drop them in a startup script and have them 
available for all of my scripts.
I've made specific requests in the past to add some support to the ESTK api for 
binding classes on demand (e.g. $.loadClass('Pages')) so that I could extend DOM 
classes more easily, but it has either fallen on deaf ears or is technically 
infeasible.
What makes this even more 'tragic' is that there is an API for adding JS 
extensions written in C. I would love to be able to selectively implement 
extensions to DOM classes in C to help get the most performance possible out of 
my scripts. Lack of a $.loadClass function makes doing this seamlessly somewhat 
impractical.

In a previous life, I used to embed interpreters (mostly TCL) into existing 
in-house applications, so my opinions might be slightly colored :)

-X