At 2000-12-12 14:01 , you wrote:
>> 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.
>
>There's always the option of leaving out the last line if the extra
>object is a problem.
For me it's no problem, as long as I keep in mind the implications of it.
>It would only mean that if you made changes to Label.prototype at
>runtime, it wouldn't affect ListItem.prototype
>
>That could either be a good thing or a bad thing, depending what
>you want.
For me personally this would be a very bad thing...
I depend on the classes be subclassable to extend the functionality, among
other things.
>I'm not sure what the problem with the extra objects is, but you
>could make your extra objects identifiable by setting the ID:
>
> ListItem.prototype = new Label('protoListItem');
>
>SD
The whole point I was trying to make is that the prototype is A Good Thing
(well...) and using object creators as constructors make the JavaScript
language in this way even more object-oriented.
It's true there is a (small) performance penalty but the added
functionality is well worth it in my opinion.
The biggest drawback IMHO with JS for now is the lack of
private/public/protected properties and methods. Instance variables can be
kludged however.
Even though the next revision of the language will have classes (finally!)
they can't be used in cross-browser environments.
/Lunna
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
