On Jan 30, 2011, at 8:32 AM, Tom Van Cutsem wrote:
...
> Right, this issue has come up before. From the "open issues" on the proxies
> wiki page:
>
> TC39 Meeting 1/28/10 The number of operators that proxies can virtualize is
> still open for discussion. The current proposal does not allow proxies to
> virtualize typeof and [[Class]]. Perhaps these could be virtualized but kept
> constant by passing appropriate values for typeof and [[Class]] to the Proxy
> constructor. The alternative API does virtualize typeof in this manner.
>
> TC39 Meeting 3/24/10 The experimental third className parameter to
> Proxy.create in spidermonkey should not be standardized. Objects should not
> be able to virtualize the [[Class]] built-in property. However,
> Object.prototype.toString.call(proxy) will reveal proxies if the object they
> are proxying has a non-Object or non-Function [[Class]].
>
> There is concern within the committee that overriding [[Class]] may violate
> spec. invariants. I believe it is Allen's intention to take issues like this
> into account in his MOP refactoring (Allen, correct me if I'm wrong).
>
> IMHO, I think being able to override the [[Class]] at least for toString()
> purposes will be required for proxies to fully fix/emulate existing host
> objects.
>
I actually think we can get rid of [[Class]]. For toString() purposes we can
provide a new, user extensible mechanism for parameterizing the default
implementation. I think most other uses of [[Class]] in the spec. really wants
to be test against the internal "class" hierarchy I identified in my recent
documents. There are other implicit "class" tests that that aren't currently
expressed in terms of [[Class]] but instead use language like "if obj is an
Array object then ...". I think we can regularize all by always being explicit
about the internal "class" of an object and using spec. language that
explicitly tests for specific internal classes.
> - I haven't tested, but according to the semantics of Array initialisers (ES5
> 11.1.4), "[]" calls "new Array() where Array is the standard built-in
> constructor with that name.". So even if I try window.Array = proxyArray,
> "[]" should not create one of my arrays. This sounds perfectly fair.
> - I obviously initialize my proxyArrays with Array.prototype as prototype. I
> haven't tested if it works; it is allowed not to, because in ES5, under each
> array prototype method is written:
> " The *** function is intentionally generic; it does not require that its
> this value be an Array object. Therefore it can be transferred to other kinds
> of objects for use as a method. Whether the *** function can be applied
> successfully to a host object is implementation-dependent. ".
> They could be reimplemented if needed to fully emulate Arrays. (I've worked
> on that a billion years ago :
> https://github.com/DavidBruant/ecma5array/blob/test_conformance/ecma5array.js)
>
> So here is another question on proxies goal/rational:
> Should proxies be powerful enough to fully emulate native Arrays? (If so and
> if ES Harmony has proxies in it, then native Array could be specified as a
> proxy which is awesome and a half in my opinion, but that's a different
> problem).
>
> As Brendan pointed out, Arrays are not host objects, they are much more
> privileged and part of the core language.
>
> To elaborate on Brendan's response, I think the point of Allen's
> MOP-refactoring is to structure the spec. such that ES-harmony has a very
> well-defined internal object hierarchy, and proxies are the mechanism by
> which JS developers can hook into that hierarchy. All existing built-ins
> (Object, String, Array, ...) are part of the predefined internal object
> hierarchy. They could or could not be defined in terms of proxies & handlers,
> but even if they would be, their traps would still be defined in terms of
> spec. language, not in terms of pure JS, to avoid over-specification and to
> allow for efficient internal representations.
The way I think about it is that the internal methods (the internal object
hierarchy) and a few abstract operations is what connects the
statement/expression level semantics of ECMAScript to the ECMAScript object
semantics. Where ever an internal method is referenced it is an indication that
some sort of object specific behavior variation is allowed. However, for
built-in objects, these variations are all explicitly defined by the
specification. It's up to implementations do decide how to implement this
semantics and as far as built-in objects are concerned there is no particular
requirement to actually implement the internal methods "calls" as actual calls.
However, if an implementation is going to support any sort of open-end host
object support then it probably does need to have code paths that do reify the
internal method calls as calls into the host object implementation layer. I
view Proxies as simply a variation on that host object implementation pattern,
but one where the reified class are reflected back into ECMASscript code.
Viewed in this manner, host objects and proxies seems to have equal expressive
power. Here host objects might have additional power would be if an
implementation provided supplemental APIs that a host object implementation
could use to directly interact with the actual runtime implementation. If some
of these implementation level back channels were common and useful enough (for
example, the ability to associate some non-property state with object
instances) then we might consider making them available in some manner to Proxy
handlers.
>
> That said, it would be very nice if the behavior of all built-ins can in fact
> be emulated via proxies. I can imagine that a tutorial on ES-harmony could
> then explain the behavior of built-ins by showing example code similar to
> your Array emulation code.
I think it is more than nice. I think it is a measure of success that we can
do this. However, I wouldn't expect the Proxy forms to be optimizable to the
same level as the built-in implementations.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
