Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

On Sep 26, 2009, at 5:20 PM, Allen Wirfs-Brock wrote:

>
>
>> -----Original Message-----
>> From: Maciej Stachowiak [mailto:mjs@apple.com]
>>
>> I expect there are relatiively few such capabilities, and little
>> interest in depending on new ones, and therefore we do not really  
>> have
>> a general ongoing problem of language design.
>>
>
> We have an ongoing problem of language design in that all new language
> features must integrate with existing features. Combinatory feature
> interactions is one of the larger challenges of language design.
>
>> From a quick scan of WebIDL, I see the following:
>>
>> 1) Catchall getters, putters, deleters, definer.
>>   - Variants that can make the catchall check happen either before
>> or after normal property lookup.
>>   - General string-based name access and index-only versions.
> No comment, I need to come up to speed on the detailed semantic  
> requirements

They are pretty similar to the way Array overrides  
[[DefineOwnProperty]] or the way String defines

>
>>   - Note: I think catchall deleters are used only by Web Storage and
>> not by other new or legacy interfaces.
>
> Seems like a strong reason to change to the proposed API to  
> eliminate the need for
> a new ES language extension.

I previously argued for removing the need for catchall deleters from  
the Web Storage API (since nothing else requires , but other browser  
vendors (including  Mozilla) were happy with it, and I think now  
everyone (including I believe Microsoft) has implemented the spec  
behavior. See prior discussion thread here: <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014851.html 
 >.  At this point, since we have multiple deployed implementations of  
Web Storage, we'd have to investigate whether it's safe to remove this  
behavior without breaking content.

>
>> 2) Ability to support being called (via [[Call]]) without being a
>> Function.
>
> Not an issue with the core ES5 semantics.  Most ES3/5 section 15  
> functions have this
> characteristic. As long as such WebIDL objects are defined similarly  
> to the "built-in"
> function they too can have this characteristic. It may well be  
> useful to introduce a
> mechanism defining such "pure" functions in the language but it  
> probably isn't necessary
> to proceed with the WebIDL binding.  The important thing to try to  
> avoid is specify
> a custom [[Call]]

I tend to agree that this behavior (and the next 3) are not  
philosophically problematic, even though they cannot today be  
implemented in pure ECMAScript.

>
>
>> 3) Ability to support being invoked a constructor (via [[Construct]])
>> without being a Function.
>
> Essentially same as 2 although the standard [[Construct]] requires a  
> [[Call]] so this
> may need some more thought.
>
>> 4) Ability to support instanceof checking (via [[HasInstance]])
>> without being a constructor (so myElement instanceof HTMLElement  
>> works).
>
> Possibly the specification of the instanceof operator needs to be  
> made extensible
>
>> 5) Ability to have [[Construct]] do something different than [[Call]]
>> instead of treating it as a [[Call]] with a freshly allocated Object
>> passed as "this".
>
> Similar to 4 regarding extensibility.  At least one recent "harmony"  
> strawman proposal is
> moving in a direction that may be relevent to 4 and 5.
> See http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_constructors

Interesting. This may provide a way to implement some of these  
behaviors in pure ECMAScript. The current proposal does allow  
[[Construct]] without [[Call]], but not [[Call]] and [[Construct]]  
that both exist but with different behavior.

Regards,
Maciej

Received on Sunday, 27 September 2009 01:09:18 UTC