W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: All ECMAScript attributes should be non-configurable

From: David Bruant <david.bruant@labri.fr>
Date: Sat, 24 Sep 2011 03:42:31 +0200
Message-ID: <4E7D3587.9090706@labri.fr>
To: Brendan Eich <brendan@mozilla.org>
CC: public-script-coord@w3.org
Le 24/09/2011 03:20, Brendan Eich a écrit :
> On Sep 23, 2011, at 6:12 PM, David Bruant wrote:
>
>>>> What is the rational behind each of these decisions?
>>> AIUI, "own" costs a direct property per instance, reified. "prototype" obviously does not.
>> What do you mean by "cost"? Is it purely an implementation concern?
> Yes.
>
>
>> If so, it doesn't seem to be for Opera and Chrome currently.
> So what? We're trying to agree on a standard, not pick some winners from the mix of five top browser vendors.
It's not really a concern of winning. 2 independent implementations made
this choice (own over inherited). This may indicate that they have been
able to efficiently implement DOM objects this way.
If the standard's motivation is implementation concerns, then we
currently have 2 proofs that the concern is not that big, so I'm not
sure the decision should be driven by this concern.

>> Regardless of ECMAScript representation (own or inherited properties),
>> the same information has to be stored in a way or another.
> No. For "own" the object itself must have a "property map" or equivalent.
For "inherited", each property must have an internal object-to-value map
or equivalent.
I agree it does not surface to ECMAScript (unlike the "own" method), but
it doesn't necessarily mean it costs less.

> It can be done pretty efficiently, but that takes more custom set-up code.
Not if the property map is lazily created.

David
Received on Saturday, 24 September 2011 01:43:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC