Subj : Re: gc questions (and various questions also)
To   : Brann Joly
From : Brendan Eich
Date : Wed May 12 2004 08:01 pm

Brann Joly wrote:
> Thx for the quick answer, brendan :)
> 
> 
>>JS_DefineObject is just shorthand for JS_NewObject; JS_DefineProperty.
>>See the source.
> 
> 
> What's the interest of defining an object as a property of another one?


You are thinking of getters and setters, but in many cases, there is no 
need for computation when fetching or storing a property value.

Linking a new object to another does indeed make it part of the live 
object graph if the "parent" object is connected to the live object 
graph, already.

JS_DefineObject is just a shorthand, it was added to the API long ago 
when many DOM level 0 objects were being created and linked into the 
window object by hand.


>>Why wouldn't you use the resolve JSClass hook instead?  Lazily creating
>>on each get adds overhead to all but the first get calls that you might
>>want to avoid.
> 
> 
> Yes, i create the object prototype only once (and i keep the Jsclass
> structure somewhere), but i'm creating objects only when they are needed,
> since i dont want my whole Dom tree to be duplicated into memory


I know, but again, if you use resolve, then you'll relieve the getter 
from having to check whether the object was already created.


>>Are these Vector objects values of properties of some other object?  If
>>you are trying to follow the DOM, might they be named by id attributes,
>>and fetched via document.getElementById?  But then they would want to be
>>DOM Elements, not just Vectors.
> 
> 
> You'r perfectly right, and my tree is not exactly Dom compliant (it's not
> mine, and things are as they are:()
> In fact, each attributes is a C++ type, and various exotic types have been
> typedefed, such as vector or others


Is this standardized in public, or anything like that?


> so what do you think of my solution, i rewrite it here :
>  I thought that i could create an object with 3 properties (x, y, z) and a
> private tag
> to my  vector in dom, with a specialized getter returning the ints to
> spidermonkey if the user tries to access x, y or z .


Sounds fine as far as it goes.  If you end up with a model more like the 
DOM than not, though, it seems like a win to normalize data in DOM terms.

/be

.