🚀 go-pugleaf

For prototyping in javacript there is loads of info on the net.
Example: <http://www.w3schools.com/jsref/jsref_prototype_math.asp>

thanks Thomas

Thomas_B._Nielsen@adobeforums.com wrote:
> For prototyping in javacript there is loads of info on the net.
> Example: <http://www.w3schools.com/jsref/jsref_prototype_math.asp>
>   

Huh? What do you gain by prototyping in that example?

The following works just as well:

function employee(name,jobtitle,born)
{
this.name=name;
this.jobtitle=jobtitle;
this.born=born;
}

var fred=new employee("Fred Flintstone","Caveman",1970);
fred.salary=20000;

-- 
Harbs
http://www.in-tools.com

You can preset a default value for all instances of employee.
This only occupies one slot in the prototype,rather than one per instance when preset in the constructor. I do it regularly for methods. Maybe run a speed test?

For methods it even works with InDesign's native objects.


// make global"Pages" object available
app.activeDocument.pages;
Pages.prototype.fancy = function ()
{
    $.writeln(this.length);
}

app.activeDocument.pages.fancy();
"Done";
// See ESTK console for output

I use prototyping a lot for standard Javascript classes like Array. The function is then available to any Array that you create. For example:

      Array.prototype.contains = function (a)
      {
        for (var r = 0; r < this.length; r++)
          {
            if (this[r] == a) { return true; }
          }
        return false;
      }





You can then just use 'myArray.contains(myValue)' to find if the value is in the Array. If you were doing this with a function, you would need to send both the Array and the value to the function, so it's a little less elegant.

Yes. I wasn't thinking of default values...

I'm very wary of prototyping standard classes. I once created a 
prototype function on the js Object class, and it caused some 
very_difficult_to_track_down bugs in another script which happened to be 
running in the same engine. Since then, I've stayed far away from 
prototyping anything besides my own private classes...

Generally, there's no need to create a prototype method to accomplish 
the goal. Simon's example is functionally equivalent to:

function Contains(array,a)
      {
        for (var r = 0; r < array.length; r++)
          {
            if (array[r] == a) { return true; }
          }
        return false;
      }
and you just write: if(Contains(array,a)){do something...}

There's actually an advantage to not use prototyping in Simon's example: My construct can be used on any object which has a length property (like strings or collections).

Dirk's example can be done in a similar way.

This is the construct that I generally use. I think it's a lot safer (albeit slghtly harder to read) than polluting the public classes...

I don't think there's any performance gain by using prototypes here.

-- 
Harbs
http://www.in-tools.com

I'm with Harbs on this one. Though it's difficult to measure these days on modern computers with their fast processors, on the sub-1Mhz-processor computers I used a few years ago, prototyped functions were clearly slower than non-prototype ones. So I never got into the habit of prototyping. They do look kinky, though.

Peter

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

When you extend these methods, do you have to do it at the top of every script? Or, is there a way to do it in an include file?

Rick Quatro

Rick_Quatro@adobeforums.com wrote:
> When you extend these methods, do you have to do it at the top of every script? Or, is there a way to do it in an include file?
> 

I have an include file (stdlib.js) that I include with almost every script I 
write. I has these extensions and other things that I commonly use.

I could also put them in a separate script and place it in the Startup Scripts 
folder so it gets loaded automatically, but that just creates problem when other 
people use my scripts.

BTW, I get around the include file distribution problem by flattening my scripts 
to a single file as part of my packaging process.

-X

One simple example where prototyping could be very bad:

function1();
function function1(){
    Array.prototype.getItemIndex = function (item){
        for(var i=0;i<this.length;i++){
            if(item==this[i]){return i}
            }
        return undefined;
        }
    var array = [1,3,5,2,4,6];
    DoSomething();
    if(array.getItemIndex(10)==undefined){
        alert("undefined");//do something
        }
    else{alert("defined")}//do something else
    }
function DoSomething(){
    Array.prototype.getItemIndex = function (item){
        for(var i=0;i<this.length;i++){
            if(item==this[i]){return i}
            }
        return -1;
        }
    //do some stuff...
    }

Now, the creator of function1 would expect his script to work properly 
-- and it will as long as he doesn't include DoSomething() in his 
script. Once he includes DoSomething() in his script, the public Array 
object has been changed to conflict with his script. The public objects 
are outside of the scope of namespaces. Both of these prototype methods 
are perfectly legitimate, but will conflict with each other, and you'll 
have a **very hard time** tracking down the problem!!!

This kind of thing can very easily happen with nested scripts especially 
when event handlers are invloved. The DoSomething() function might not 
even be in your script, and you might not know of its existence... Of 
course using private scripting engines avoids these issues when used 
carefully, but I'd rather keep everything in its own namespace and safe 
from any chance of conflicts...

-- 
Harbs
http://www.in-tools.com

Why not use the "Export As XHTML" solution?

Adding a folder inside the Scripts folder (Not scripts panel), and making a subdir of this with the name Startup scripts.

I can see where you are coming from, Harbs, but my example was just that, an example. In many other instances you would need separate functions for different data types and in those instances there would no benefit to using a function instead of an prototype. In fact, as I stated, in many situations it is often far more elegant to use a prototype because you pass less arguments.

There is a lot more to be said about when and where to use prototypes but in the end it will probably come down to an individual's goal in terms of how they want their code to be structured. None of the reasons given here, besides potential performance impact, really touch on the reasons why prototypes are beneficial.

In the context of the original question, however, it seems that we can probably say they have very little impact on the way someone might approach scripting InDesign (unknown performance impact issues aside). You can choose to use them, or choose not to. Put it this way, when you have written enough code that organisation through class structure and inheritence becomes key to efficiency, then prototyping will be something you want, rather than something you need.