Subj : Re: Array-like calls... I'm totally confused now :-( To : Andreas Podgurski From : Brendan Eich Date : Sat Feb 07 2004 02:26 pm Andreas Podgurski wrote: >In the getter/setter of the class, I'm receiving method calls, too. Great thing, opens very new frontiers on using SpiderMonkey, but how do I still tell the engine, that it was tried to access a property that doesn't exist? Before using this callback it was clear, the property setter/getter was there, methods where defined, but now I would have to go through both lists myself to make sure no >not existing property passes through, or am I wrong? > If you want references to properties other than those that you predefine to be errors, then you must report the error yourself, which suggests that you have to check. Usually, class getters and setters (implemented by non-stub JSClass getProperty and setProperty members) use switch statements on JSVAL_TO_INT(id), first ensuring that JSVAL_IS_INT(id). The int-valued ids are those you predefine (by convention, usually negative numbers starting from -1 and decrementing), in the tinyid member of each JSPropertySpec struct in the |ps| array passed to JS_InitClass or JS_DefineProperties, or a tinyid passed via the |tinyid| parameter to JS_DefinePropertyWithTinyId. If a property was not predefined by you as having a tinyid, then the id passed to the class getter or setter will either be !JSVAL_IS_INT(id) -- it will be the case that JSVAL_IS_STRING(id) and you can report an error there -- or the id will not be in the dense range [-n, -1] of tinyids that you predefine. This does allow people to refer to your predefined properties via obj[-1], obj[-2], etc. for obj.firstPredefinedPropertyWithTinyid, etc. That's a quirk but it doesnt' seem to harm anything. If you don't use tinyids, then your shared, class-wide getter and setter will have to look up string and int ids in a more general way, say in a hash table, and if no predefined property exists with the given id, you'll have to report an error. The DOM embeddings in MozillaClassic used tinyids for switch-based dispatch to property-specific code inline within shared class-wide getters and setters. See http://lxr.mozilla.org/mozilla/search?string=JSPropertySpec, where some more modern, still compiled in Mozilla uses show up too. The js/src/liveconnect Java<=>JS bridge of course uses java.lang.reflect to look up Java fields and methods and reflect them as JS properties, so it does not use tinyids. BTW, it's unusual for JS embeddings to make errors out of such non-predefined property references. Why do you want to do that? There may be good reasons, of course. It's just not commonly done. > The confusion started, because I expected to come the hard coded properties to come through this callback as well, but I've never seen it (What doesn't exactly has to mean it wasn't there). > What do you mean by "hard coded properties"? If you use JS_DefineProperty and give a particular property its own getter and setter, only those functions will be called -- not the class getProperty and setProperty hooks. > It's hard to >debug a part which is run through so repeatedly... > > Maybe you don't want to use the default, class-wide getter and setter for your properties. You do know you can give each property its own getter and setter, right? See JS_DefineProperty etc. >Second, is there anywhere a documentation or tutorial which describers all callback possibilities of SpiderMonkey? > Have you browsed http://www.mozilla.org/js/spidermonkey/ yet? /be .