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 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
