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

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

From: Simon Pieters <simonp@opera.com>
Date: Sat, 27 Aug 2011 00:02:33 +0200
To: "Allen Wirfs-Brock" <allen@wirfs-brock.com>
Cc: "Jonas Sicking" <jonas@sicking.cc>, public-script-coord@w3.org
Message-ID: <op.v0ucujenidj3kv@simon-pieterss-macbook.local>
On Fri, 26 Aug 2011 23:19:11 +0200, Allen Wirfs-Brock  
<allen@wirfs-brock.com> wrote:

>> 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.

OK.

> 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.

Why does it cause confusion? Is it because the constants are enumerable on  
the instance?


> 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.

I'm not convinced that making it inconsistent among Web APIs where  
constants appear will reduce overall confusion. However, if we decide to  
do this we first need to research which APIs need the dual appearance for  
compat.


>> 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).

Thanks.

> 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.

Yep.

-- 
Simon Pieters
Opera Software
Received on Friday, 26 August 2011 22:03:32 UTC

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