Let's kill terms "native" and "host"
Tom Van Cutsem
tomvc.be at gmail.com
Tue Jan 31 03:40:54 PST 2012
2012/1/30 Brendan Eich <brendan at mozilla.org>
> Andreas Rossberg wrote:
>> On 30 January 2012 20:17, Oliver Hunt<oliver at apple.com> wrote:
>>> > From the PoV of JSC I suspect our biggest problem will actually be
>>> our API, which essentially allows developers to override an arbitrary
>>> collection of [[SomeInternalMethod]] methods, potentially inconsistently (a
>>> sad fact of our api is that you can override [[HasProperty]] and
>>> [[GetProperty]] independently, and have them be inconsistent:(
>> Well, it's not like the language's own object API (a.k.a. proxies) is
>> any better in that respect...;)
> It's still a win to have fewer such mouths to feed, and in particular,
> only one such mouth in the spec. I hope you're just reminding that proxies
> can be abused to violate invariants that we cannot enforce (efficiently or
> at all), not putting proxies into the same low class as JSC's (or
> SpiderMonkey's, or any other engine's) old/over-broad embedding API.
Proxies (also direct proxies) can indeed expose inconsistencies between
fundamental and derived traps, but throwing away the derived traps in favor
of removing such inconsistencies seems like a bridge too far. Not only is
there economy of expression to consider (it's logical that the expression
|name in obj| triggers a "has" trap that directly corresponds to the
intercepted operation), but derived traps in general need to perform less
object allocations to produce a result.
For instance, if the expression |name in obj| would trigger the
"getOwnPropertyDescriptor" trap instead of the "has" trap, a property
descriptor could be allocated only to have the in-operator test whether the
descriptor is undefined.
Also, we provide the VirtualHandler API <
http://wiki.ecmascript.org/doku.php?id=harmony:virtual_object_api> to make
it easier for developers to just implement fundamental traps and inherit
derived trap fallback implementations. When used properly, proxies with
such a handler will never be internally inconsistent.
So, I don't think "derived" internal methods such as [[HasProperty]]
necessarily need to be refactored, other than to the extent described in
the "proto climbing refactoring" proposal <
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss