At 2000-12-12 00:03 , you wrote:
>I think it's always better not to say MyObject.prototype=new DynObject
(That makes me understand SuperClass better...)
>Reasoning: We shouldn't want instance variables to be prototype variables.
>All variables initialized within the DynObject constructor will become part
>of the prototype.
>Why do we want this? Variables should be initialized at the time the
>instance is created, no sooner.
>I remember having a problem when I was trying to use the prototype to make
>sure a variable was available at the time the instance was created. I found
>that the variable space was shared. Especially if a varaible is an object.
>This could cause undefined behavior of other widgets downline.
Well, that's the problem with the prototype-based way.
Because the prototype is an object that is used when looking up a
property/method that the "class" doesn't implement itself, setting unique
properties should be done in the creator function instead, with a call to the
creator function for the immediate superclass.
For example the ListItem class:
function ListItem(text,value)
{
this.superClass = Label;
this.superClass(text);
this.value = value;
...
}
ListItem.prototype = new Label();
Perfect, except for the fact that one object is wasted to set the prototype.
But the prototype chain is right!
>I like the idea of setting the prototypes equal.. it seems more direct, and
>doesn't set instances of objects as prototypes of another.
But that's the way inheritance in JavaScript works...
And how would it work if you want to make a subclass of a subclass? And call a
superclass' method?
/Lunna
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
