pls explain abt prototype

Report · Jan 19, 2009

pls explain abt prototype and its use in indesign scripting

Report · Jan 19, 2009

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

Report · Jan 20, 2009

Thomas_B._Nielsen@adobeforums.com wrote:
> For prototyping in javacript there is loads of info on the net.
> Example:
>

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

The following works just as well:

funct...

Report · Jan 20, 2009

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 == 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

Report · Jan 21, 2009

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

Report · Feb 02, 2009

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.

Report · Jan 20, 2009

thanks Thomas

Report · Jan 20, 2009

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

Report · Jan 20, 2009

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 == 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.

I love Dirk's tip for prototyping built-in InDesign classes. I can see how that would be useful.

Report · Jan 21, 2009

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

Report · Jan 21, 2009

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

Report · Jan 21, 2009

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

Report · Jan 21, 2009

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

Report · Jan 21, 2009

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.