[webkit-dev] Qtish API for JavaScriptCore

[Kent Hansen]

Hi Oliver,

ext Oliver Hunt wrote:
> I am concerned about the performance impact of changing  
> getPropertyNames, as well as correctness -- getPropertyNames does  
> specifically exist for the support of for..in enumeration.
>   

Any concerns about adding a separate function for that, then (i.e.
getNonEnumerablePropertyNames())? JSC would not use that function
itself, it would just give us a chance to introspect JS objects and our
own host objects. Of course, it'd mean keeping that function working
whenever there's e.g. a refactoring/restructuring of
JSObject::getPropertyNames() (only once every full moon, right? :-) ).

>   
>> - Being able to delete a property from C++ even if the property has
>> DontDelete=true. We implemented this by adding a checkDelete  
>> argument to
>> JSObject::deleteProperty(). I think it's similar in spirit to the put 
>> ()
>> methods that have a checkReadOnly argument. The patch is not that  
>> large
>> compared to the getPropertyNames() change, because there aren't as  
>> many
>> classes reimplementing deleteProperty().
>>     
>
> I'm not sure what you're saying here.
>   

In our API, the attributes of a property affect JS access, but not C++
access. E.g. if a property is ReadOnly, it can't be changed from JS, but
can still be changed from C++. Same thing with DontDelete.


>   
>> - Storing CallFrame::callee() as a generic JSObject instead of a
>> JSFunction. Any JSObject can be invoked as long as its getCallData()
>> returns something, so we didn't see a good reason for only being  
>> able to
>> store JS callees (in the QtScript API we need to offer the callee for
>> native functions as well).
>>     
> I'd be very careful with a change like this.  Especially given the  
> inspector debugger is already able to do what you're claiming you  
> needed to change JSC to support.
>   

OK. We'll take a look at the Inspector and see if we can do what it
does. The change just made it possible to streamline our code, that's all.

> The debugger is not API, and should not be depended upon.  If you are  
> interacting with the debugger you are not using the JSC API, and so  
> you will not be able to rely on JSC not changing and breaking your API.
>   

That's perfectly understandable, and it's something we (as in "not you")
have to live with for the time being.


> These really should already be in bugs.webkit.org, as i've said i'm  
> kind of concerned about some of the changes you've described so it  
> would have helped you to talk to us earlier.
>   

Thanks for the concern, but please don't lose any sleep due to us. :-)
We're not out to "lock down" JSC due to our own API requirements.
FWIW, for the most part, layering our API on top of JSC has been
straightforward. Can't all be sunshine, of course.

Regards,
Kent