Re: All ECMAScript attributes should be non-configurable

Travis Leithead a écrit :
> +IE9 (another example using configurable properties--as accessor properties on the prototypes). We did work around the performance issue using caches, as most sites don't mess with the configurability of the properties.
What performance issue are you refering to? Brendan's argument was
actually that this design was better in terms of performance.

> We [Microsoft] are strong supporters of the "configurable" DOM type-system. While you can "destroy-the-world" you can also use that power for good (with great power comes great responsibility . Thanks to configurable properties, we were able to build a very useful tool to help all web developers identify potential compatibility problems on their web sites.
>
> http://blogs.msdn.com/b/ie/archive/2011/04/27/ie9-compat-inspector.aspx
>
> The tool is simple and replaces built-in DOM APIs with an inspection layer before funneling the calls through to the actual APIs. If the various accessor properties weren't configurable this tool would not be possible.
>From the code I have read, the tool only replaces some functions
("operations" in WebIDL terms). Not attributes. By "attributes", I refer
to the definition in WebIDL: http://www.w3.org/TR/WebIDL/#es-attributes
. This is also the definition I used in my original message when I was
talking about "attributes".
As you can see, "attributes" do not cover "operations". Operations are
configurable as they have always been. It's a great feature, i don't
want to change it.

Currently, in Chrome, attributes are not inherited. Operations are, but
attributes are not. Attributes are exposed as own properties when the
object (event for instance) is created. This guarantees by design, that
all event object have a "target" property for instance.
This guarantee is lost in WebIDL because of inheritance +
non-configurability. I think it's a loss. You may disagree and i'd would
like to hear arguments against it.

As said Brendan
(http://lists.w3.org/Archives/Public/public-script-coord/2011JulSep/0457.html
): "A non-configurable prototype property could not be deleted, which
would remove the destroy-the-world hazard. It could still be shadowed,
but not by assignment -- only by Object.defineProperty."

So I don't really see what is the problem with having attributes (and
only attributes, not operations!) non-configurable.


Le 30/09/2011 20:33, Erik Arvidsson a écrit :
> - Infinity
>
> I'm with Travis and Alex here. Configurability is part of JavaScript
> and the web.
I agree partly. This pattern of "object attributes represented as a
configurable inherited getter/setter pair" has never been part of the
web. Not the standardized web  at least (mostly because of a lack of
specification I think).
Configurability of operation has always been, I agree and I won't
suggest to touch it.

> If you don't want this I suggest using a static language like GWT/Java
> or use Caja or AdSafe (or some other linter like tool).
>
> erik
>
> On Wed, Sep 28, 2011 at 19:44, Alex Russell <slightlyoff@google.com
> <mailto:slightlyoff@google.com>> wrote:
>
>     I hate this idea.
>
Did you understand it as I just re-explained it?

David
>
>
>     On Fri, Sep 23, 2011 at 12:31 PM, David Bruant
>     <david.bruant@labri.fr <mailto:david.bruant@labri.fr>> wrote:
>     > Hi,
>     >
>     > In the current form of WebIDL, if i run the following code (in a
>     > WebIDL-compliant environment):
>     > -----
>     > var o = Event.prototype;
>     > delete o.currentTarget; // works with any other attributes
>     > -----
>     > Then, all events afterward will not have a currentTarget
>     property (since
>     > it's gone from the interface).
>     > In the DOM event spec, "currentTarget" is defined as an
>     attribute on the
>     > Event.prototype object. This property must be a configurable
>     (since not
>     > [[Unforgeable]]). Consequently, any script can remove it and
>     events will
>     > no longer have a currentTarget property which is not what anyone
>     want.
>     >
>     > Consequently, I would suggest to consider all attributes to be
>     > non-configurable regardless of [[Unforgeab(le)]]-ility.
>     >
>     > David
>     >
>     >
>
>