[webkit-dev] JS: Getter/Setter callbacks at Property level

Geoffrey Garen ggaren at apple.com
Mon Jul 20 13:27:56 PDT 2009

> I'm not sure you get exactly what I'm saying as you put class in  
> places where I'd expect property.  For instance:
> "
> I looked briefly, and it seems like it would be relatively easy to  
> add an API for adding C getters and setters to a class individually.  
> So, that seems like a reasonable feature request. "
> Replacing class with property is what I'd expect here, i.e., each  
> property set on an object has it's own getter and setter.  Something  
> like:
> void  
> JSObjectSetPropertyWithCallback 
> (ctx 
> ,object 
> ,propertyName 
> ,value,getterFunction,setterFunction,attributres,exception);

What I was referring to when talking about classes was that  
JavaScriptCore has an API for defining classes, and an API for making  
JavaScript objects that instantiate those classes. Currently, that's  
how the API accommodates C getters and setters.

> Also I'm a little worried about the word "dynamic", these are  
> definitely static.  I have all the functions created, you just have  
> a pointer to them.  If the pointer exist, call it for the value and  
> break out.  If it doesn't, go down the chain.

What I meant by "dynamic" was that getters and setters that are not  
pre-defined as a part of a class are dynamically added to objects in  
an ad hoc manner, thereby defeating many optimizations in the object  

It would be trivial for the object system to efficiently handle the  
instruction "add this getter / setter to all objects of this class."

It would be challenging, and require substantial design thinking, for  
the object system to efficiently handle thousands of instances of the  
instruction "add this getter / setter to this object."

> 1) I don't need to define classes for objects; right now, the only  
> reason I would need to create classes (instead of just passing NULL)  
> is to setup the getters & setters.  This reduces workload and  
> generalizes a lot of my code

Indeed, it's a bit more code to create a class, add getters and  
setters to it, and then create an object with that class, than it  
would be to add getters and setters directly to an object. But I don't  
think it's a prohibitive increase in code -- do you?

> 2) The JS engine has already looked up the property by name; with  
> class based getters/setters, I also have to lookup the property by  
> name.  With property based getters/setters, it's only looked up once  
> and directly called to me.  This should be a big savings win and  
> should be more simple at the back end (if there's no getter/setter  
> associated with a property, just skip forward down the chain.)

I don't understand the optimization you're describing here, but I can  
tell that, given the current design of JavaScriptCore, classes are  
more efficient than ad hoc properties.


More information about the webkit-dev mailing list