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

First paragraph of ECMAScript binding of attributes shouldn't immediately be constrained further

From: Geoffrey Sneddon <gsneddon@opera.com>
Date: Sun, 17 Jul 2011 20:47:01 +0100
Message-ID: <4E233C35.7030708@opera.com>
To: public-script-coord@w3.org
Currently the paragraph reads: "For each attribute defined on the 
interface, there must be a corresponding property either on the 
interface prototype object or on every object that implements the 
interface, unless…"

The following paragraph goes on to define what is on the prototype 
object and what goes on every object that implements the interface. Just 
reading that paragraph, it'd appear that the implementation has a choice 
as to where attributes can be placed (leading to misinformation, when 
the answer to that question is seeked without reading the entire 
specification).

It'd seem preferable that the specification said something like, "For 
each attribute defined on the interface, there must be a corresponding 
property either on the interface prototype object or on every object 
that implements the interface, *depending on the [Unforgeable] extended 
attribute as defined below,* unless…".

Alternatively, a more radical change would be to change it to:

"For each attribute defined on the interface, there must be a 
corresponding property, unless:

the identifier of the attribute is “constructor”; or
the identifier of the attribute is “toString” and the interface has a 
stringifier.

If the attribute was declared with the [Unforgeable] extended attribute, 
then the property must exist on every object that implements the 
interface. Otherwise, it must exist on the interface’s interface 
prototype object."

This avoids the duplication of the constraint, and keeps the requirement 
as to where the attribute must be placed in one place, both of which 
seem like reasonable goals.

-- 
Geoffrey Sneddon — Opera Software
<http://gsnedders.com>
<http://opera.com>
Received on Sunday, 17 July 2011 19:47:39 UTC

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