dynapi-dev

Re: [Dynapi-Dev] Inheritance

[Scott A. L. <sc...@sc...>]

On the face of it I don't think it's entirely necessary unless your goal is
to create a large hierarchy of objects, in which case you could just use the
SuperClass object as your base object and subclass everything from there.

The WidgetX model will create an extra instance of the DynLayer class in the
DynLayer unassigned[] collection, for every constructor that uses
"WidgetName.prototype = new DynLayer();" to fake inheritance.  But that
shouldn't break anything, just as long as unassigned[] remains private and
you don't loop through it for anything.

------
scott andrew lepera
sc...@sc...
web stuff: www.scottandrew.com
music stuff: www.walkingbirds.com


-----Original Message-----
From: Brandon Myers <bnd...@ho...>
To: dyn...@li... <dyn...@li...>
Date: Monday, December 11, 2000 6:14 PM
Subject: RE: [Dynapi-Dev] Inheritance


>>> Wouldn't it be better to say:
>>> MyObject.prototype = DynObject.prototype
>
>>I guess this would only create a pointer, so that changes to
>>MyObject.prototype would affect DynObject.prototype
>
>Very good point.. so should we then loop through the prototypes?..
>Assigning the individual functions, but not the entire prototype?
>Do this to avoid setting variables or objects which would then be shared by
>all instances of the subclass.
>
>function Label() {
> this.theLayer=new DynLayer();
>}
>
>Label.prototype=new DynObject();
>
>Then.....
>
>function Button() {
> this.theLayer.addEventListner(Button.mouseEvents);
>// More stuff here too.
>}
>Button.mouseEvents=...blah blah blah....
>Button.prototype=new Label(); // Cause a button is just a label with
events.
>
>Now.. guess what? All instances of Button will share the same DynLayer
>reference.
>Is this what is intended? I don't think so.
>
>Now.. don't get on my case that I used Dan's original widget model.. it's
>just a practical example. Any object in place of the "theLayer" object
would
>have the same problems.
>
>-----Original Message-----
>From: dyn...@li...
>[mailto:dyn...@li...]On Behalf Of Simon Dicon
>Montford
>Sent: Monday, December 11, 2000 6:12 PM
>To: dyn...@li...
>Subject: RE: [Dynapi-Dev] Inheritance
>
>
>> I was wondering the point of this line when inheriting objects:
>>
>> MyObject.prototype = new DynObject();
>
>It's so that any changes to DynObject.prototype at runtime will
>be reflected in MyObject.prototype
>
>> Wouldn't it be better to say:
>> MyObject.prototype = DynObject.prototype
>
>I guess this would only create a pointer, so that changes to
>MyObject.prototype would affect DynObject.prototype
>
>SD
>_______________________________________________
>Dynapi-Dev mailing list
>Dyn...@li...
>http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>
>_______________________________________________
>Dynapi-Dev mailing list
>Dyn...@li...
>http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

RE: [Dynapi-Dev] Inheritance

[Pascal B. <pb...@oi...>]

The whole prototype code is THE way that Javascript does inheriting (read
the Netscape references) The problem we are facing is something we did our
selves, in the constructor we should only SET the properties, not create
properties or methods, that causes problems.

This also means that the oncreate eventlistener is not correct, I think we
should restate the oncreate method of an object, because that makes it work
correctly in multy-chain inheriting. See my latest preview release of
dynacore, the image button inherites from the button which inherits from the
dynLayer which inherits from the DynObject.. that's multi chain inheriting
with events and everything working correctly.

The only problem, as Robert pointed out, is the unassigned element with the
wrong ID, this is the only thing I have to get out but the problem exists
because we are creating a new array-element in the constructor.. which
should not be done.

Note that this problem only exists because we overwrite the ID value in
later object constructors.



Pascal Bestebroer
pb...@oi...
http://www.oibv.com


-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens Scott Andrew
LePera
Verzonden: dinsdag 12 december 2000 8:49
Aan: dyn...@li...
Onderwerp: Re: [Dynapi-Dev] Inheritance


On the face of it I don't think it's entirely necessary unless your goal is
to create a large hierarchy of objects, in which case you could just use the
SuperClass object as your base object and subclass everything from there.

The WidgetX model will create an extra instance of the DynLayer class in the
DynLayer unassigned[] collection, for every constructor that uses
"WidgetName.prototype = new DynLayer();" to fake inheritance.  But that
shouldn't break anything, just as long as unassigned[] remains private and
you don't loop through it for anything.

------
scott andrew lepera
sc...@sc...
web stuff: www.scottandrew.com
music stuff: www.walkingbirds.com


-----Original Message-----
From: Brandon Myers <bnd...@ho...>
To: dyn...@li... <dyn...@li...>
Date: Monday, December 11, 2000 6:14 PM
Subject: RE: [Dynapi-Dev] Inheritance


>>> Wouldn't it be better to say:
>>> MyObject.prototype = DynObject.prototype
>
>>I guess this would only create a pointer, so that changes to
>>MyObject.prototype would affect DynObject.prototype
>
>Very good point.. so should we then loop through the prototypes?..
>Assigning the individual functions, but not the entire prototype?
>Do this to avoid setting variables or objects which would then be shared by
>all instances of the subclass.
>
>function Label() {
> this.theLayer=new DynLayer();
>}
>
>Label.prototype=new DynObject();
>
>Then.....
>
>function Button() {
> this.theLayer.addEventListner(Button.mouseEvents);
>// More stuff here too.
>}
>Button.mouseEvents=...blah blah blah....
>Button.prototype=new Label(); // Cause a button is just a label with
events.
>
>Now.. guess what? All instances of Button will share the same DynLayer
>reference.
>Is this what is intended? I don't think so.
>
>Now.. don't get on my case that I used Dan's original widget model.. it's
>just a practical example. Any object in place of the "theLayer" object
would
>have the same problems.
>
>-----Original Message-----
>From: dyn...@li...
>[mailto:dyn...@li...]On Behalf Of Simon Dicon
>Montford
>Sent: Monday, December 11, 2000 6:12 PM
>To: dyn...@li...
>Subject: RE: [Dynapi-Dev] Inheritance
>
>
>> I was wondering the point of this line when inheriting objects:
>>
>> MyObject.prototype = new DynObject();
>
>It's so that any changes to DynObject.prototype at runtime will
>be reflected in MyObject.prototype
>
>> Wouldn't it be better to say:
>> MyObject.prototype = DynObject.prototype
>
>I guess this would only create a pointer, so that changes to
>MyObject.prototype would affect DynObject.prototype
>
>SD
>_______________________________________________
>Dynapi-Dev mailing list
>Dyn...@li...
>http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>
>_______________________________________________
>Dynapi-Dev mailing list
>Dyn...@li...
>http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

RE: [Dynapi-Dev] Inheritance

[Brandon M. <bnd...@ho...>]

> -----Original Message-----
> From: Pascal Bestebroer
> Sent: Tuesday, December 12, 2000 3:01 AM
> To: dyn...@li...
> Subject: RE: [Dynapi-Dev] Inheritance
>
>
> The whole prototype code is THE way that Javascript does inheriting (read
> the Netscape references) The problem we are facing is something we did our
> selves, in the constructor we should only SET the properties, not create
> properties or methods, that causes problems.
>
Ya can't set properties if you don't first create them... And specifying of
properties is usually done in a constructor. BUT, there's no point in
calling the superclass's constructor if you already have the values set in
the prototype.
Right.. so if we are trying to code any sort of inheritance, then we must
first make sure we are doing it correctly before we make a monster. The API
wasn't originally coded to do what you are doing... it was originally coded
to do exactly what I suggested:  loop through the prototype object and copy
each instance.. (See Dan's original DynAPI 2 release with the
widgetinterface object)

Ok.. so he was trying to implement some sort of inheritance... it worked,
but had a few problems that could have been worked out. So, we go with the
built-in prototype inheritance... We must then think of a standard way that
DynLayers, or ANY object that will be used as an ancestor for inheritance,
to be defined, and instanciated, without breaking any of the other rules of
inheritance, or causing any other anomolies. We seem to be focused in
fitting this well rounded API into an oval inheritance hole. (Prototype
inheritance isn't a well rounded method of inheritance). It just won't fit
in it's current state. So... if people still want to use inheritance why not
just take a few steps back, and take a good look at how the API is put
together and integrated with the other parts. Then spin an altered structure
which allows simple, stable inheritance without memory leaks, or anomolies.

It's not going to get done unless someone just does it. I have my way,
Pascal has his, and you guys have yours.

> This also means that the oncreate eventlistener is not correct, I think we
> should restate the oncreate method of an object, because that
> makes it work correctly in multy-chain inheriting.

All inheritance should be done BEFORE any instances are created.. if we do
the inheritance each time an instance is created.. there would be a
performance hit. Why not get that over with at the begining. Or not do
inheritance at all.

>See my latest preview release of
> dynacore, the image button inherites from the button which
> inherits from the
> dynLayer which inherits from the DynObject.. that's multi chain inheriting
> with events and everything working correctly.
>
> The only problem, as Robert pointed out, is the unassigned
> element with the
> wrong ID, this is the only thing I have to get out but the problem exists
> because we are creating a new array-element in the constructor.. which
> should not be done.
>
> Note that this problem only exists because we overwrite the ID value in
> later object constructors.
>
>
>
> Pascal Bestebroer
> pb...@oi...
> http://www.oibv.com
>

RE: [Dynapi-Dev] Inheritance

[Pascal B. <pa...@dy...>]

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Brandon Myers
> Verzonden: dinsdag 12 december 2000 17:28
> Aan: dyn...@li...
> Onderwerp: RE: [Dynapi-Dev] Inheritance

> Ya can't set properties if you don't first create them... And
> specifying of
> properties is usually done in a constructor. BUT, there's no point in
> calling the superclass's constructor if you already have the values set in
> the prototype.
> Right.. so if we are trying to code any sort of inheritance, then we must
> first make sure we are doing it correctly before we make a
> monster. The API
> wasn't originally coded to do what you are doing... it was
> originally coded
> to do exactly what I suggested:  loop through the prototype
> object and copy
> each instance.. (See Dan's original DynAPI 2 release with the
> widgetinterface object)


The properties are created with prototyping not in the constructor.
Properties belong to the object and are part of the prototype. Why wasn't
the API coded that way? I know Dan's original code was using that whole
widgetinterface but as Dan pointed out a few weeks ago we both feel that
normal prototyping is good enough to do widgets.. still not sure what the
problem is with prototyping, just look at my example it's working with
multiple widgets, sub-class inheriting and events triggering correctly.


> Ok.. so he was trying to implement some sort of inheritance... it worked,
> but had a few problems that could have been worked out. So, we go with the
> built-in prototype inheritance... We must then think of a
> standard way that
> DynLayers, or ANY object that will be used as an ancestor for inheritance,
> to be defined, and instanciated, without breaking any of the
> other rules of
> inheritance, or causing any other anomolies.

Correct, we're now using the built-in (to javascript) prototyp inheriting,
would you create your own superclass methods for C++ or Delphi aswell?
That's the way the language does it, so why not use it without adding extra
code that can contain extra bugs and uses extra memory and download time?
And what rules of inheriting are we breaking? (what rules are there!?)

> We seem to be focused in
> fitting this well rounded API into an oval inheritance hole. (Prototype
> inheritance isn't a well rounded method of inheritance). It just won't fit
> in it's current state. So... if people still want to use
> inheritance why not
> just take a few steps back, and take a good look at how the API is put
> together and integrated with the other parts. Then spin an
> altered structure
> which allows simple, stable inheritance without memory leaks, or
> anomolies.

The API is not put into an inheriting model, the widgets/UI components are.
The prototyping is stable and without memory leaks and I think it should be
obvious by now that it's the most simple way of doing it.

> It's not going to get done unless someone just does it. I have my way,
> Pascal has his, and you guys have yours.


> > This also means that the oncreate eventlistener is not correct,
> I think we
> > should restate the oncreate method of an object, because that
> > makes it work correctly in multy-chain inheriting.
> All inheritance should be done BEFORE any instances are created.. if we do
> the inheritance each time an instance is created.. there would be a
> performance hit. Why not get that over with at the begining. Or not do
> inheritance at all.

I totally agree, something that is done in prototyping seeing that the
prototyp of the object is inheriting from the object BEFORE the instance is
created.. it just sets the object's prototype chain once the file is read..

The only thing we should remember is that you just can't do creation code
inside the constructor because Javascript handles an object just like a
function, it parses and executes the code everytime it's called.. that's the
way Javascript works.


I guess will never agree on this one ;)

Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net