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

On Aug 26, 2011, at 1:19 PM, Simon Pieters wrote:

> On Fri, 26 Aug 2011 16:43:11 +0200, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote:
> 
>> 
>> I agree.  My original point was regarding whether the replication of constants on both interface objects and interface prototype object be wired into WebIDL (as it current is specified) or should it be done explicitly on a case by case basis  where it is needed for web compat for existing APIs.
> 
> I don't see the advantage in introducing an inconsistency between existing APIs and new APIs here. I think it would confuse authors who are used to now constants work in existing APIs and expect them to be the same in new APIs.

My assumption is that JavaScript programmers will be most familiar with JS code and coding conventions. In JS, you have to explicitly define a property twice to get it to appear on both a constructor (ie, an interface object) and on a prototype object. This is seldom done. 

The problem is that  some past Web API practices (apparently Java & C++ inspired) which are now being proposed for codification in WebIDL don't follow typical JS conventions. This means that web APIs already creates confusion for JS programmers. Many web developers do not make a strong distinction between browser Web APIs objects, built-in native JS libraries, and API objects provided by third party frameworks and libraries.  They are already confused because the Web APIs don't follow the native JS conventions used buy built-ins and most libraries and frameworks.

We can keep increasing the confusion by continuing to define more Web APIs that deviate from JS norms or we can try to stabilize the level of confusion by making sure that all new APIs look and behave like native JS APIs. For existing APIs we need to maintain compatibility but we can also work to make sure that those APIs include a subset of operations and attributes that make sense from a JS perspective. 

> 
> 
>> For example we could allow a "static" prefix on const definitions in which case Node might be coded as:
>> 
>> interface Node {
>>   ...
>>   const unsigned short ELEMENT_NODE = 1;
>>   static const unsigned short ELEMENT_NODE = 1;
>>   ...
>> }
>> 
>> making it explicit that ELEMENT_NODE exists "on both sides".  New API's could be encouraged to adopted the more normal ECMAScript convention and only define the "static" constant.
> 
> Could you cite an example of a constant that follows that convention? (Is the convention to define the constant on the interface object or on the prototype?)

Constants would are more normally defined on the constructor (ie, the interface object).  A good example is the ECMAScript Number constructor (ES5.1 section 15.7) which defines a number of constant property on the constructor (15.7.3).

The place you see something different would be a singleton object such as the Math object which defines both some constants and some functions but is not a constructor and has no instances other than itself. This is probably best thought of as a namespace object that contains discrete constant and function definitions rather than as a "class" of objects.

Allen