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

[Brian Barnes]

How about separate call backs at the class level?  That would solve my  
problem with minimal code movement.  Something like:

JSClassSetPropertyGetterSetter(ctx,class,"red",myRedGetter,myRedSetter);

Would that be more within the design?

BTW, thanks for listening and leading me through some things.  I'm  
basically just asking for an API to save me trouble (though other  
engines have it, so it's not outside the realm) -- and you guys paying  
attention and talking me through things I don't know is very helpful.

[>] Brian


On Jul 20, 2009, at 4:27 PM, Geoffrey Garen wrote:

>> 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  
> system.
>
> 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.
>
> Geoff