Subj : Re: using  js_HashString in a getter callback
To   : netscape.public.mozilla.jseng
From : Brann Joly
Date : Tue May 25 2004 01:02 pm

> > For methods, i'm storing the private data this way :
> >      JSFunction* func = JS_DefineFunction(cx, i->second.first,
_decl.name,
> > jslangage::generic_wrapper, n, 0);
> >  JS_SetPrivate(cx, JS_GetFunctionObject(func), &_decl);
>
> Don't you mean JS_SetReservedSlot, not JS_SetPrivate, here?

I meant JS_SetPrivate, but of course I may be wrong. What I want is to
attach some data to a function object, so I can get it back when my callback
is called by SM. Since I use JS_SetPrivate to attach private data to
objects, i thought it was a good idea to use it for functions too. What's
the difference between the 2 functions? I can't find JS_SetReservedSlot in
the apidoc


> The engine internalizes ids as atoms, ensuring uniqueness.  So a get or
> set of "foo" will result in the same jsval id being passed every time,
> no matter how "foo" was computed by the caller.

I have here a little problem that is not totally SM related, but maybe
there's in SM a feature i'm missing that would solve my problem.
My types are created at runtime, and may inherit from other dynamic types.
Also, types are totally dynamic, and new functions and properties can be
added. Say two objects (A and B) both have a "foo" property, how would my
generic wrapper make the difference (since both "foo" will result in the
same id passed to my callback). A solution would be to use a map for each
type, mapping an id to the thing to do, but what if the property is
inherited.

As far as I have sorted things out, I have two solutions here: I can either
look for the id in the object map, and then in the parent's map, and so on
till i find it, or I can propagate the parent's maps into child's maps.
(First option is bad for performance. Second option is better, but a bit
tricky because of dynamic creation of properties).
I'm also thinking of taking the best of the two solutions, (ie propagate map
only when object is created, and assume that only a few properties will be
created dynamically, and go up the inheritance tree for those ones.

Is there a better solution? Am I missing a key SM feature here?$

thx for helping !

Brann

.