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

On 8/31/11, Cameron McCormack <cam@mcc.id.au> wrote:
> 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.)
>
Not sure if it was considered, but element ID or NAME will create a
corresponding property in certain cases, just as it is all too easy to
make the mistake:

<input name="submit" type="submit">

- which creates a `submit` property on the form's `elements` collection.


>
>> 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:
>
In Java, an interface's properties are all public static final, even
if not explicitly declared so, and the implementation of that
interface has them as such, with those modifiers. In Java, static
members are visible on the instance. They're not inherited in the same
way that instance members are, but are visible, much like prototype
members are visible in JavaScript.

And so having Node.ELEMENT_NODE visible on Node instances is congruent
with that.

> 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.
>
Yep, more like JS and borrowing less from Java thinking.

> 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.)
>
Allows for more granular specification at the cost of an extra
internal property and the consideration of when to use it.
-- 
Garrett

Received on Thursday, 1 September 2011 06:06:28 UTC