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