Child.prototype = new Parent; vs. Child.prototype.__proto__ = Parent.prototype;

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Child.prototype = new Parent; vs. Child.prototype.__proto__ = Parent.prototype;

Daniel Friesen
The normal pattern currently for making one Prototypal class inherit
from another has always been:

function Parent() {}
function Child() {}
Child.prototype = new Parent;

Setting the child prototype to a new Parent object is just used to
create an object in the prototype chain which has __proto__ pointed
correctly basically. I'm wondering if there is any downside I can't
think of for using this method instead:

function Parent() {}
function Child() {}
Child.prototype.__proto__ = Parent.prototype;

Yes, I can think of the two possible issues, but neither are issues for me:
A) __proto__ is Mozilla only;
=> I'm in a {Spider|Trace}Monkey server environment, I'll never be
without the Mozilla improvements so I'm basically coding in a pure moz
environment, portability is of no concern (if it was I wouldn't be using
getters and iterators as much as I do).
B) Using new Parent also puts methods created inside of the parent
constructor itself into the prototype chain, while setting __proto__
directly doesn't;
=> I know, however methods created inside the parent constructor are
normally meant to be tied to the instance, not to the prototype chain
Moreover normally the only reason to put the creation of a public method
inside of the constructor is to have access to the closure scope, this
is not something that should really be put into the prototype chain so
inheritance wise it might be best to make sure they don't get into the
chain.


Unless someone else can come up with a serious defect with using the
latter pattern that I can't think of, I think I might create an inherits
function inside of my library environment and start using a pattern like:

function Parent() {}
function Child() {}
Child.inherits(Parent);

Where:

Function.prototype.inherits = function(from) {
    this.__proto__ = from;
    this.prototype.__proto__ = from.prototype;
};


Actually this has the theoretical advantage of also inheriting /static/
methods.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com]
-Nadir-Point (http://nadir-point.com)
-Wiki-Tools (http://wiki-tools.com)
-MonkeyScript (http://monkeyscript.nadir-point.com)
-Animepedia (http://anime.wikia.com)
-Narutopedia (http://naruto.wikia.com)
-Soul Eater Wiki (http://souleater.wikia.com)

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Child.prototype = new Parent; vs. Child.prototype.__proto__ = Parent.prototype;

Jason Orendorff-2
On 1/21/09 11:24 AM, Daniel Friesen wrote:
> The normal pattern currently for making one Prototypal class inherit
> from another has always been:
>
> function Parent() {}
> function Child() {}
> Child.prototype = new Parent;

Add to this the line:
  Child.prototype.constructor = Child;

> Setting the child prototype to a new Parent object is just used to
> create an object in the prototype chain which has __proto__ pointed
> correctly basically. I'm wondering if there is any downside I can't
> think of for using this method instead:
>
> function Parent() {}
> function Child() {}
> Child.prototype.__proto__ = Parent.prototype;

The danger is that assigning a non-null value to __proto__, or assigning
anything to __proto__ after an object is fully initialized, might stop
working in the future.  This is not so far-fetched: I've heard Brendan
plan to kill that feature several times.

The rationale would be that the constraint that an object's __proto__
won't change is more valuable than the feature.  In particular, (a) the
JIT could likely take advantage of the constraint to generate faster
code; (b) the constraint might be necessary for a future optional static
type system to provide the integrity and speed we expect from such
systems.  The type system that was proposed for ES4 included this
constraint.

> Function.prototype.inherits = function(from) {
>     this.__proto__ = from;
>     this.prototype.__proto__ = from.prototype;
> };
>
> Actually this has the theoretical advantage of also inheriting /static/
> methods.

Yes, that's true.  In fact they would behave like Python's classmethods:
'this' in the body of such a method would be the constructor function.
You could say things like "new this()".

Alas, I don't think that feature is worth the risk that it'll just stop
working at some point.

-j
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Implementing class-based inheritance with SpiderMonkey[Scanned]

Spriggs, Jim
Hi Guys,

In the recent thread "Child.prototype = new Parent; vs. Child.prototype.__proto__ =Parent.prototype" Jason Orendorff wrote:

> > The normal pattern currently for making one Prototypal
> class inherit
> > from another has always been:
> >
> > function Parent() {}
> > function Child() {}
> > Child.prototype = new Parent;
>
> Add to this the line:
>   Child.prototype.constructor = Child;
>

Is there a recommended JSAPI-phrase (or set of phrases) for implementing this idiom with custom objects in SpiderMonkey?

Background:
I'm currently using the method that Jens Thiele presents here:
 http://egachine.berlios.de/embedding-sm-best-practice/ar01s05.html#id2526037

This works for me just fine (Thanks , Jens!), but as the man himself implies, the necessary hack is non-obvious.

A couple of years have flown by since then, so I was wondering if anyone is aware of a better mouse-trap having been invented in the meantime?

Thanks for any clues!
--
Jim Spriggs
RAYLASE AG


RAYLASE AG
Argelsrieder Feld 2+4
82234 Wessling/Oberpfaffenhofen
Germany
Tel.: +49-(0)8153/88 98-0
Fax: +49-(0)8153/88 98-10
http://www.raylase.de

District Court Munich, HRB 131450

Board: Peter von Jan (CEO), Alistair Gill, Erwin Wagner

Supervisory Board: Dr. Ulrich Lohmann (Chairman)
--
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Implementing class-based inheritance with SpiderMonkey[Scanned]

Jason Orendorff-2
In reply to this post by Jason Orendorff-2
On 1/23/09 9:26 AM, Jim Spriggs wrote:

>> function Parent() {}
>> function Child() {}
>> Child.prototype = new Parent;
>> Child.prototype.constructor = Child;
>
> Is there a recommended JSAPI-phrase (or set of phrases) for implementing this idiom with custom objects in SpiderMonkey?
>
> Background:
> I'm currently using the method that Jens Thiele presents here:
>   http://egachine.berlios.de/embedding-sm-best-practice/ar01s05.html#id2526037

Hmm.  That's not quite how I would do it, but it'll do.  There's no
standard idiom as far as I know.

(No matter what you do, methods that access private data must always
check that `this` is the right type of object first, and this is a bit
trickier when you're talking about a C++ class lattice than when you
just have stand-alone custom classes.  Thiele uses dynamic_cast for the
check.)

-j
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

AW: Implementing class-based inheritance with SpiderMonkey[Scanned][MESSAGE NOT SCANNED]

Spriggs, Jim
On Fr 23.01.2009 23:23, Jason Orendorff wrote:
> (No matter what you do, methods that access private data must
> always check that `this` is the right type of object first,
> and this is a bit trickier when you're talking about a C++
> class lattice than when you just have stand-alone custom
> classes.  Thiele uses dynamic_cast for the
> check.)

Hmm, so in the meantime I've been reconsidering my whole approach.

If anyone is willing to bear with me and give me a quick reality check, I'd be very grateful!


I have a small number of native classes forming a (very) shallow tree: a single Native_Base and a bunch of direct descendents, call them Native_[ABC].
My goal is to make their functions and attributes available via JS_[ABC] custom objects, so that, say, a JS_A object would instantiate and use a private Native_A, and so forth.

It seems to me that I basically have two choices:

1) Avoid the inheritance problem completely by flattening the Native_[ABC] + Native_Base interface at the JSAPI level.
This appears to have the disadvantage of requiring a lot of essentially duplicate code in the getters/setters/function-wrappers because each JS_[ABC] is forced to deal independently with all the Native_Base::stuff in addition to it's own Native_[ABC]::stuff.

2) Find a way to mirror the Native inheritance at JSAPI level, so that the JS_[ABC]'s can offload all the Native_Base::stuff onto JS_Base.
The disadvantage is obvious in this case, I think ;-)


So now I'm wondering if #2 was maybe the wrong choice after all?
Perhaps someone has already implemented #1 and found it wasn't so painful as I think?
Is there a #3?


Tnx for listening :-)

--
jim



RAYLASE AG
Argelsrieder Feld 2+4
82234 Wessling/Oberpfaffenhofen
Germany
Tel.: +49-(0)8153/88 98-0
Fax: +49-(0)8153/88 98-10
http://www.raylase.de

District Court Munich, HRB 131450

Board: Peter von Jan (CEO), Alistair Gill, Erwin Wagner

Supervisory Board: Dr. Ulrich Lohmann (Chairman)
--
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine