Subj : Re: (Spidermonkey) Converting a property name to a tinyId
To   : netscape.public.mozilla.jseng
From : zakalawe@mac.com (James Turner)
Date : Mon Mar 17 2003 03:56 pm

> Couldn't you use JS_GetProperty and JS_SetProperty to do the getting and 
> setting from native code?  True, those have to hash the property name, 
> but so would any JS_GetPropertyTinyId that takes a const char *name 
> parameter.  Anyway, hashing a string is cheaper by orders than executing 
> a precompiled script, which is cheaper by far in turn than compiling 
> (evaluating).

This would be fine, but the problem is I have code in the get/set path
that I don't want to execute in this case.

I'll try to explain this, since it will also bring up another minor
niggle I'm having. I have classes defined in C++, with the expectation
they will be 'sub-classed' in JS. The JSClass defines custom getter,
setters and adds for properties (and maybe delete too, eventually). In
the property ops, the code path looks like

// this method is static
jsbool MyBaseClass::mySetProperty(JSContext *ctx, JSObject* obj, jsval
prop, jsval *value)
{
    MyBaseClass *ins = (MybaseClass*) JS_GetPrivate(ctx, obj);

   ... do some common bookeeping code to mark 'ins' as dirty, ensure
it's writeable, etc ....

    if (JSVAL_IS_INT(prop)) 
        ins->setBuiltinProperty(JSVAL_TO_INT(prop), value);
    else {
        .... simulate the default behaviour of SetProperty ....
    }

}

The reason I need the tinyId mapping is I want to invoke
setBuiltinProperty (but not the bookeeping code) from some other
place. The impl of setBuiltinProperty (which is a virtual method
overriden by things inheriting from MyBaseClass) is basically a big
switch, and the numerical IDs work, so having to do the manual lookup
is awkard. I will happily use the function you provided, it's up to
you whether it's API worthy.

The other 'niggle' raised here is that for *non* built-in properties
(whether ad-hoc or obtained from the prototype), I cannot see a way to
get the default behaviour for add/get/setProperty. Which is annoying,
since I'm currently having to replicate it. This is clearly silly, so
is there some way around this?

The reason for all this jumping through hoops is that the common
'book-keeping' code is absolutely vital, so I know which objects are
dirty, and can doing things like proxying all get/set property calls
over a network connection.

So, as far as I'm concerned, the tinyId accessor is useful, but maybe
not useful enough for you. Ditto on the 'be able to invoke the default
behaviour' in impls of property operations.

As usual, thanks for the help,
James

.