[webkit-dev] Qtish API for JavaScriptCore

[Kent Hansen]

ext Simon Hausmann wrote:
> Hi Oliver,
>
> On Wednesday 26 August 2009 11:04:29 pm ext Oliver Hunt wrote:
>   
>> A further
>> issue is that any API that binds directly to JSC internals
>> realistically needs to be developed by the engineers working on the
>> core engine as a developing such an API needs enormous care to not
>> cause harmful long term problems.
>>     
>
> I understand that. We've been bitten by that, too, as we've ported our 
> existing API to JSC internals, to see how it can be done. The vast majority 
> was straight forward as we've been careful in the original design to only 
> expose what you can do in JavaScript itself. In a few places we've made 
> mistakes but we've found solutions for them, too, that don't affect the 
> internals in flexibility or performance. (*pokes some of the guys to elaborate 
> a bit here*)
>   


Hi,
Here's a rough overview of JSC hacking we've been doing:

- Fixing purely ECMA-compliance-related things. These are mostly small
discrepancies we've found when running our tests; the associated JSC
patches should be straightforward to either accept or reject (we'll be
creating separate Bugzilla tasks for these). If they're not fixed, it's
not critical for us, as I doubt much real-world JS depends on the
behavior anyway (otherwise you'd think the issues would have been fixed
already).

- Adding ability to introspect non-enumerable properties of objects from
C++. JSObject::getPropertyNames() seems to be made only to support the
JS for..in statement; we added an extra parameter so you could ask for
non-enumerable properties as well. We need this for debugging and
autocompletion. The patch is large because there are a lot of classes
that reimplement getPropertyNames(), so all the signatures must be
updated... I'm interested in hearing if there are alternatives, e.g.
adding a separate virtual function getNonEnumerablePropertyNames() and
only implement it in JSObject for a start (and we would then reimplement
it in our own Qt "bridge" classes).
See also https://bugs.webkit.org/show_bug.cgi?id=19119; looks like the
Inspector would also gain from providing this functionality.

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

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

- Some more flexibility in dealing with timeouts: Make TimeoutChecker
subclassable so we can get a callback at timeout, make it possible to
adjust the timeout interval.

- Adding column number information to the parser + debugger callback.
Not life-critical, but reasonably easy to add to the parser anyway.

- Hacking error.sourceURL and error.line to be called error.fileName and
error.lineNumber instead. We don't know how many existing QtScript users
out there rely on the fileName and lineNumber properties being present
on error objects, though; maybe we can make the source-incompatible
change JS-wise of using the JSC names. A safer solution would be to just
copy sourceURL and line over to fileName and lineNumber in the parts of
our code where we have the chance to do that (i.e. not inside JSC itself).

- Trying to make our debugger callbacks (which we relay from the JSC
debugger callbacks) have precisely the same semantics as in our old
engine. We have a similar debugging interface as JSC::Debugger, but
obviously "similar" doesn't cut it for this low-level stuff. Geoffrey
Garen said in another mail in this thread that the debugger exposed too
much internal engine knowledge, and that's also true for the API we
provide for QtScript.

We'll be creating Bugzilla tasks with patches for the things we hope
make sense to get upstream (regardless of whether the QtScript API
itself makes it upstream at some point, which I agree is not very
reasonable so long as it depends on JSC internals), so we can discuss
any implications in more detail.

Regards,
Kent