Re: [WebIDL] troublesome names, property attributes and related issues

On 26/08/11 11:37 AM, Allen Wirfs-Brock wrote:
> Because the use of 'prototype', 'constructor', and probably 'toString'
> as attribute or operation names is problematic for ES, WebIDL section 3
> should probably simply reserve those names and say that they can't be
> used as attribute, operation, or constant names. If you want to be more
> precise 'prototype' probably only needs to be reserved from use as a
> static operation name and 'constructor' as a non-static operation,
> attribute or constant name.

Yes, I agree, it's simpler just to disallow these names.  (The change 
has already been made as part of addressing timeless' comments.)

> 4.3.8 [NoInterfaceObject]
>
> What if an [NoInterfaceObject] interface has static operations? Would
> this be an invalid WebIDL fragment? This case also doesn't appear to be
> covered by 4.5.6.

Good point, I will disallow this.

> 4.5.4 Constants
>
> This section says that constants must be defined as properties on both
> the interface prototype object and the interface object. Browsers don't
> currently seem to do this. Try document.ELEMENT_NODE and
> Document.ELEMENT_NODE
> (http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-1950641247 ).

(Earlier messages in the thread point out that we should be looking at 
say document.ELEMENT_NODE and Node.ELEMENT_NODE here, and that all 
browsers do put properties in both places:

http://people.mozilla.org/~cmccormack/tests/constant-prototype.html)

...
> It would be good for new API designs to use the more normal JS
> constructor only convention for constants. You could encourage this by
> specify in 4.5.6 that constants normally only appear as properties on
> the interface object. For compatibility with existing web APIs that have
> constants on the instances you could use a new extended attributes,
> perhaps [PrototypeProperty], to indicate that the constant should also
> be defined on the interface prototype object. This gives you backwards
> compatibility and migrates existing APIs to expose constants on
> interface objects.

Yes, that'd be the way to do it if we want to avoid properties for 
constants on interface prototype objects for future APIs.  (I don't 
think using "static" to indiacte "only put it on the interface object" 
is best, because spec authors would tend not to use it.)

I agree with Simon's points earlier in the thread, though.  I feel that 
having the current set of APIs use enumerable properties but newer ones 
use non-enumerable properties would cause at least the same order of 
magnitude confusion as recognising that JS libraries do not have 
constant properties on prototypes by do have them on constructors.

Some crude Google Code Search searching found some libraries that do 
look up constant properties on instances for at least one constant on 
each of Node, DOMException, Event, HTMLMediaElement, MediaError and 
ApplicationCache.  So it seems some people do expect DOM constants to 
exist on instances for newish APIs, probably extrapolating from Node 
etc.  We could break these authors' expectations for future APIs if we 
wanted.  Is it worth it?

> 4.5.4 defines the ES property attributes for constants as {
> [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }.
> While I don't particularly disagree with the settings for [[Writable]]
> and [[Configurable]] I do need to point out that this is different from
> what is currently implemented by FF, IE9, and Chrome for ELEMENT_NODE
> and probably other constants. If this is seen as an acceptable change
> from current browser practice then I have to also question the
> [[Enumerable]] setting. The ES norm is for properties that represent
> constants to be non-enumerable. See for example ES5.1 15.7.3.2-15.7.3.6
> and 15.8.1.1-15.8.18. This precedent suggests that the ES binding for
> WebIDL constants should define them as [[Enumerable]]: false.

Firefox is the odd one out when it comes to writable/configurable; 
Chrome/Safari/IE all have them non-writable/non-configurable.  My guess 
is that this change is safe enough due to the divergence in behaviour.

On the other hand, the property is enumerable in all of Firefox/Chrome/
Safari/IE.  I would be wary of making them non-enumerable.

> Similarly, 4.5.6 says that operations turn into properties that are
> [[Enumerable]]: true while the ES convention for built-in object
> abstractions is for method properties to be [[Enumerable]]: false.
> Future versions of ES that will provide direct support for defining
> methods and/or class-like abstractions will also default user defined
> methods to [[Enumerable]]: false. It would be more forward looking for
> WebIDL to do the same for operations.

Again, I think we probably can't change the enumerability of properties 
corresponding to operations, since all browsers do have them enumerable, 
and it's quite likely sites depend on them being enumerable.

> If you use the ES built-in objects as examplars you will generally see
> that it is only properties that in some way represent actual program
> data that are made [[Enumerable]]: true.

Oh, I never inferred that before, thanks.

Received on Thursday, 1 September 2011 04:02:41 UTC