[webkit-dev] Qtish API for JavaScriptCore

[Oliver Hunt]

On Sep 1, 2009, at 10:30 AM, Kent Hansen wrote:

> 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? :-) ).

We'll probably need this logic for Object.getPropertyNames in ES5, my  
concern is the implementation and performance impact, as well as  
correctness in the context of caching.

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

A C++ object can expose a binding to JS where DontDelete or Readonly  
properties may disappear or change (the JSC API allows this) -- but  
don't let your C++ API delete non-deletable JS properties, it's  
unnecessary and would be a willful violation of the spec for no  
reason.  The ES5 spec says quite explicitly that a property that is  
marked as DontDelete may not be removed -- adding an API that both  
requires changes to JSC for non-compatibility reasons, that in turn  
require a violation of the spec is bogus.

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

And when you want to continue to support your API in future and we rip  
out the current model entirely? then what?  JSC does not have an API  
to allow debugging, you should just live with this for the time being  
rather than trying to expose a fairly broken model using non-API  
functions.

--Oliver

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090901/da6c95c2/attachment.html>