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

[Mark S. Miller]

On Wed, Sep 7, 2011 at 6:40 AM, David Bruant <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.

-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110907/baa34ec8/attachment.html>