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

On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote:

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

"(including Mozilla)" and "happy with it" leave out some nuance:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014856.html

Robert O'Callahan here wrote "If overloading "delete" is too quirky or  
too hard to implement, then it seems none of the other shorthands  
should be allowed either." His message adverted to the better course  
of methodical access instead of property access to Web Storage keyed  
values.

Alas Rob finally gave up at:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014868.html

I think the Web Storage key/value reflection as properties is a  
mistake. Sorry I wasn't reviewing it in time to say so. But it was  
obviously not a situation everyone was "happy" with, even ignoring the  
issue of delete.


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

We could try to remove it -- or (what is more likely to go down  
easily) we could add methods and let the property reflections wither,  
and vow to avoid repeating this mistake.


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

What does typeof say for such a callable object?

In what sense are any DOM methods required to be not Functions (native  
function objects) in the specs? In Netscape of old and Mozilla  
browsers since 1998, DOM methods are native function objects.

This seems winning since developers want not only sane typeof,  
but .apply/call/bind.

We've talked on es-discuss about "pure" functions (ones without  
[[Construct]] and .prototype) before:

https://mail.mozilla.org/pipermail/es5-discuss/2009-July/002920.html

in case you missed the thread. Agreed it's not a big deal. We have a  
bugzilla.mozilla.org bug on file to fix our built-in functions (Date  
methods, etc.) to lose [[Construct]] and .prototype. I'm not sure of  
v8's plans.

First-class syntax for defining such non-constructor functions is  
elusive. ;-)


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

Is there anything specified via WebIDL that must be a constructor but  
not a callable?

Ye olde Image and Option, at least, act like most built-in  
constructors by constructing when called, at least in Gecko and I  
think IE -- but not in WebKit (I just tested).


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

Definitely.


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

As an aside, the strawman for 'constructor' makes at least Mark Miller  
and me want to unify 'class' and 'constructor' -- we don't want both,  
and Harmony needs something already called class for several reasons,  
one of them to model built-ins in ES1-5.


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

Date needs the latter.

/be

Received on Sunday, 27 September 2009 03:06:59 UTC