[Harmony Proxies] Non-extensible, sealed and frozen Proxies
david.bruant at labri.fr
Thu Sep 8 05:12:01 PDT 2011
Le 07/09/2011 17:35, Mark S. Miller a écrit :
> On Wed, Sep 7, 2011 at 6:40 AM, David Bruant <david.bruant at labri.fr
> <mailto:david.bruant at labri.fr>> wrote:
>> How about we adapt ideas from the "<|" proposal?
> This proposal is only about initializing the prototype. I don't
> see what can be adapted to work on [[Class]].
> Agreed that it's quite different. My think was a bit muddy.
> The [[Class]] magic that <| does derives from having a literal
> expression on the right side, determining the [[Class]] of the result
> while not determining the [[Prototype]] of the result. The cool thing
> about depending on a literal in this position is we get to delegate to
> the literal initialization logic the issue of initializing the
> instance so it has the right own invariants. The proposal works
> because none of the invariants associated with any existing [[Class]]
> rely on the instance's [[Prototype]]. The cost if relying on syntax in
> this way is we can't leverage this to create and initialize, say, a
> true Date which inherits from something other than Date.prototype. We
> could if we introduced a Date literal, but that's a terrible way out
> of the dilemma.
> The Date example also points out what's wrong about just inheriting
> the [[Class]] and its associated internal vtable. Things which check
> for the Date [[Class]] assume the Date invariants are maintained. A
> proxy emulation of a Date must uphold these invariants.
> Which suggests a bizarre idea. What if the optional third argument
> were the object to serve the role of Tom's fixedProps object? Then the
> proxy's [[Class]] would be the fixedProp's [[Class]], and Tom's
> enforcement mechanism would magically enforce whatever invariants are
> associated with [[Class]]. This should work for NodeLists and other
> host objects as well.
So the third argument would be the object the proxy would become. This
sounds like a reasonable idea but is a bit different from the original
fix proposal which created a fresh object based on an object description
I guess I should ask: why in the original design did the author had to
return a description of the object to be returned rather than creating
the object himself and return it? To avoid returning a proxy, maybe?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss