Subj : Re: [SpiderMonkey] prototypes and millions of objects
To   : Brian Barnes
From : Brendan Eich
Date : Sat May 15 2004 09:44 am

Brian Barnes wrote:

> Question #1: My engine depends on private data from the objects to work 
> right.  If I have a prototype, and I get a set or get property call, 
> will I get the private data from the object or from the prototype (the 
> property will be on the prototype.)


The obj parameter is the directly-referenced object, with its private 
data of course attached.  Finding a property in a prototype does not 
change the |this| parameter binding for methods, or the implicit |this| 
(obj in API nomenclature) passed to getters and setters.


> If it's the prototype, then I can't  use them :(


That would defeat the purpose, wouldn't it? ;-)

If your getter and setter are manipulating value storage in private 
data, then you don't need any object slot allocated by the engine, so 
you should define such properties with the JSPROP_SHARED attribute.


> Question #2:  As I'm experimenting, I noticed something.  I do this 
> little trick where each class I use I override the "add property" stub, 
> and if a flag tells me I'm in creation, then to let adds go through.  
> Otherwise, fail them.  This turns off people's ability to add to my 
> objects.  This doesn't work when using prototypes because if I use the 
> same class for the prototype as I do the real object, the real object 
> triggers this add before actually checking the prototype for the 
> property!  Is this some optimization?


No, it sounds like you are actually defining or setting a property on 
the "real" object (the directly-referenced object, as I put it above). 
Otherwise addProperty would not be called.  Debug a little, the stack 
backtrace will show what's going on.


> Question #3: When creating the "real" object (using JS_DefineObject) 
> from the prototype, do I need to really set any class since that class 
> is all set in the prototype?  Could I use a stubed class (or null, for 
> that matter?)  that might solve #2.


This makes no sense.  Are you creating a new object?  That's what 
JS_DefineObject does, and then it names it -- it's a shorthand for 
JS_NewObject followed by JS_DefineProperty.  If you have an object 
already and you wish to name it as a property of another object, just 
use JS_DefineProperty.

/be

.