Re: [WebIDL] Indexed properties and [[Extensible]]

[+tvcutsem]

Both ES5 host objects and the proxies proposal require an object to either
reject an attempt to freeze / seal / preventExtensions on it, or, if they
let such an attempt succeed, they must then behave as a frozen / seal /
non-extensible object. In ES5.1 the relevant language is at the end of 8.6.2
starting with

"The [[GetOwnProperty]] internal method of a host object must conform to the
> following

invariants for each property of the host object:"


For proxies, the way a handler indicates a refusal to become frozen / seal /
non-extensible by having its fixed trap return undefined.

It would violate the letter and spirit of both spec to allow a freeze
attempt to appear to succeed on an object that then does not behave as a
frozen object.


On Wed, May 25, 2011 at 5:52 PM, Cameron McCormack <cam@mcc.id.au> wrote:

> Jonas Sicking:
> > How do named/indexed getters/setters interact with the prototype
> > chain? Are they supposed to show up as properties on the object
> > itself, or should they show up as "catch all" getters on an object on
> > the proto chain?
>
> They are currently required to show up as properties on the object
> itself.  After http://www.w3.org/mid/20110503052431.GN2576@wok.mcc.id.au
> it seems like the spec should switch back to specifying [[Get]],
> [[Put]], etc. to make them catch-alls.  As I said in the thread, I think
> it’s a cleaner / easier model to think about.
>
> > The latter is how we implement them in Firefox. The former might be
> > more javascripty since it doesn't require catch-alls.
> >
> > If it's the latter, then this isn't a problem at all since when you
> > freeze, you only freeze the object itself. Objects on the prototype
> > chain aren't affected at all.
>
> You’re arguing that since the catch-alls are already a layer on top of
> the existing object, that we could make freeze() etc. succeed but have
> that catch-all layer ignore it, just as it ignores whatever properties
> are on the object underneath when it goes to create a new named
> property?  I think the only problem with this is that the proxy trap to
> fix an object with freeze, seal or preventExtensions must return a
> static description of an object that the proxy “becomes”, so it wouldn’t
> be possible to make, say, preventExtensions() cause existing named
> properties continue to be live while new ones cannot be created.  As far
> as I understand the proxy proposal.
>
> --
> Cameron McCormack ≝ http://mcc.id.au/
>
>


-- 
    Cheers,
    --MarkM