[Harmony Proxies] Non-extensible, sealed and frozen Proxies

[David Bruant]

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

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110908/fde31da8/attachment-0001.html>