Subj : Re: [Q] Parent objects, prototypes, inheritance and JS_InitClass...
To   : netscape.public.mozilla.jseng
From : Brendan Eich <brendan@meer.net>
Date : Wed Nov 19 2003 02:08 pm

t o b e wrote:

>Please help me with my understanding and correct me where I'm wrong:
>
>==
>
>Inheritance in Javascript is expressed through a chain of prototype objects.
>Each call to JS_InitClass takes an argument which is the prototype of the
>superclass and returns the prototype to the new class which is then passed
>to either JS_NewObject or JS_DefineObject to create an actual instance of
>the class.
>
>==
>
>Given this I've got the following questions:
>
>In JS_InitClass, what exactly is the second argument 'obj' used for. I seem
>to get decent results passing almost any JSObject in except NULL.. The API
>doc simply says 'Pointer to the object to use for initializing the class'.
>Eh ? Initializing in what way ? And why is it necessary to provide the
>property and function specs for the parent prototype in this situation ?
>  
>

(The docs *ache*.)

The ||obj| (second) param to JS_InitClass and also to the vast majority 
of the API's entry points is the scope chain head object.  It typically 
will be the global object; in the case of JS_InitClass, it should be.  
That object need not be cx->globalObject (the member hidden behind 
JS_{Get,Set}GlobalObject), but it can be.  You should consider the 
cx->globalObject member a handy way to associate a global object per 
context, but if you don't need it, don't worry about it.

If you pass some other object to JS_InitClass as the |obj| param, that's 
the object in which a property naming the class constructor (if the 
|constructor| param you pass is non-null) or class prototype (if you 
pass null for |constructor|, as Math, e.g., does) will be defined by 
JS_InitClass.  So Object, String, Date, etc. are all properties of the 
global object naming class constructors, and your class constructors 
generally should follow suit.

>Why do JS_DefineObject and JS_NewObject take arguments to both a JSClass and
>a prototype. ?
>

So you can override the prototype if you need to.

> Is the class argument completely redundant when an existing
>prototype is available ?
>

If you have your hands on the right prototype object, pass it to 
JS_{Define,New}Object -- that will speed up the call, because the engine 
won't have to find the class prototype by looking up the class name in 
the scope chain.  If you don't have the prototype in hand and you want 
the class prototype to be used, pass NULL.

> Also.. what exactly is the 'parent' argument to
>these calls for. Can anyone define what 'parent' means in this context ??
>  
>

All objects in SpiderMonkey have a __parent__ internal property.  This 
generalizes the [[Scope]] internal property specified only for Function 
objects by ECMA-262 Edition 3.  It's the link in the scope chain.

So an activation of a function F can be thought of as an object 
(sometimes it is an object, of class |Call| in SpiderMonkey; but for 
most functions, the activation object is optimized away) called A, whose 
__parent__ is initialized from F.__parent__.  For a single global object 
embedding, all scope chains end in the global object.  But consider a 
browser embedding: each window or frame/iframe is a global object.  
Defining F in W1 and calling it from script loaded in W2 must work so 
that A.__parent__ is F.__parent__ is W1, not W2.  To make the scope 
chain for the activation of F from W2 link to W2 would be "dynamic 
scoping" -- contrary to good programming language design and experience, 
as well as to the ECMA standard.

>I also don't have a clue what 'constructors' are for.. apart form
>initializing members, of course..
>

That's reason number one.

> the docs suggest they allow you to specify
>static functions and properties for JSObjects but what this means precisely
>in a Javascript context I'm not sure...
>  
>

The "static" term comes from Java. If you think of the class constructor 
as a class name, then Math.PI, Number.POSITIVE_INFINITY, etc. should 
remind you Java static fields.  Likewise for methods (which are just 
function-valued properties) such as Date.parse.

>And lastly.. but by no means least.. are there any better
>guides/explanations to embedding Javascript than the rather cursory ones
>available on the mozilla website  ?
>

Franky Braem has a site, but I forget the URL.  Google his name, or 
perhaps someone will followup here.

> Any books you'd recommend ?
>  
>

Not that I know of.

/be

.