W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2015

Re: Should properties on the named properties object be readonly?

From: Mark S. Miller <erights@google.com>
Date: Thu, 2 Apr 2015 15:45:07 -0400
Message-ID: <CABHxS9ggBHwTGVc8-rsZADv6DWjnd4WAQ0kGmR_v6z+24Uc=eg@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
Ok, I understand this response, but perhaps not your original message. If
the property on the named properties object isn't changeable, is the only
reason for setting [[Writable]] to true to avoid the override mistake? (If
so, I agree this is an adequate reason.)

On Thu, Apr 2, 2015 at 3:26 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 4/2/15 3:04 PM, Mark S. Miller wrote:
>
>> If you initialize [[Writable]] to true, allow assignments, and have the
>> resulting value be the value assigned
>>
>
> Hold on.
>
> Let's look at my testcase again:
>
>         <div id="x"></div>
>         <script>
>           x = 5;
>           alert(x);
>         </script>
>
> When this script runs, its environment is the global environment.  The
> global has an object (the "named properties object"; it's very like a
> proxy) on its prototype chain which has the special [[GetOwnProperty]]/[[DefineOwnProperty]]
> under discussion.  Its [[GetOwnProperty]] for "x" returns a descriptor for
> a value property whose value is the <div> element.
>
> The bareword assignment is happening with the global as receiver.  So if
> the "x" property on the named properties object is writable, then
> assignment to x as above will [[DefineOwnProperty]] on the global itself,
> not on the named properties object.  All good so far.
>
> Now let's consider this testcase:
>
>         <div id="x"></div>
>         <script>
>           x = 5;
>           delete x;
>           alert(x);
>         </script>
>
> This alerts "[object HTMLDivElement]" in all browsers, as expected:
> nothing ever changed the value of the "x" property on the named properties
> object; we just shadowed it, then deleted the shadowing property.
>
> So it's not that we have the "resulting value be the value assigned";
> we're just shadowing.
>
>  why not have [[DefineOwnProperty]] also succeed for these cases?
>>
>
> So this is really about cases in which someone does assingment directly on
> the named properties object, not on the global, or does an
> Object.defineProperty on the named properties object.
>
> We _could_ allow people to do that.  It requires a lot more complexity in
> spec and implementations in terms of defining the interaction of the
> proxy-like bits of the named properties object and these user-defined
> properties.  It's a lot simpler to just say that this particular proxy
> never allows properties to be added to it, other than the ones its handler
> wants to expose, than to specify/implement how it should behave if it were
> to allow them.
>
> -Boris
>



-- 
    Cheers,
    --MarkM
Received on Thursday, 2 April 2015 19:45:35 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 2 April 2015 19:45:35 UTC