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

On Sep 26, 2009, at 8:05 PM, Brendan Eich wrote:

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

I accept your corrections as to nuance. At the time I felt like I was  
fighting a losing battle. The real issue, though, is what to do going  
forward.

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

There are methods, but I'm not optimistic that they will cause  
property reflection to wither.

If the number of places in the Web platform that require custom delete  
behavior goes from 1 to 2, that's a lot less bad than going from 0 to  
1. So it won't accomplish much. However, I missed a spot and it looks  
like custom deleters are also used by the DOMStringMap interface,  
which is used to reflect data-* attributes. <http://dev.w3.org/html5/spec/Overview.html#domstringmap-0 
 > I don't think anyone has implemented that yet.

I believe we could get rid of custom deleters from the Web platform if  
Firefox and IE remove support for custom deleters in LocalStorage,  
refuse to add it back, and refuse to implement it for DOMStringMap. If  
that happened, I'm sure other browsers and the spec would follow suit.  
I don't think I can convince my colleagues to remove the behavior from  
WebKit if Gecko and Trident continue to support it.


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

I think it should probably say "object", though that's not compatible  
with ES3 or current WebKit practice.

>
> 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 is not an issue for DOM methods. It's an issue for interfaces  
such as HTMLCollection and HTMLFormElement that support indexing by  
function call syntax, for legacy compatibility reasons. Constructors  
like XMLHttpRequest, Option and Image also do not inherit from  
Function.prototype even though they are callable.

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

It's definitely winning, and it may be possible to apply it to global  
constructors that are also callable as a future improvement, but it's  
probably not possible to make HTMLCollection or HTMLFormElement  
inherit from the Function prototype, and I think it would not be  
desirable either.

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

This reminds me that I forgot to specifically call out the ability to  
have a function that implements [[Calll]] but not [[Construct]]  
(assuming that's not subsumed in giving them the ability to be  
different).


Perhaps it's sufficient to provide an API for altering the [[Call]]  
and [[Construct]] behavior of an existing object without a first-class  
syntax, following in the spirit of defineOwnProperty(). Something like  
foo.defineOperation("construct", funcToCallWhenConstructing). This  
would address all of points 2 to 5, for ECMAScript implementations  
that wish to precisely replicate DOM behavior. This approach could  
also be used for index getters/setters/has-testers, general catchall  
getters/setters/has-testers, removing either one of call or construct  
while retaining the other, making call and construct do different  
things, and perhaps other useses. And using a method instead of first- 
class syntax would let scripts feature-test for this capability.

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

I did not specify "without being callable", just without inheriting  
from Function. Currently, Image, Option and XMLHttpRequest are  
examples of interfaces that make use of this point #3. They do not  
have .apply or .call methods in any browser.

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

My testing seems to indicate not in IE. Likewise for XMLHttpRequest.  
We should probably specify one way or the other whether these are  
callable and stick to it. I am indifferent as to which behavior we  
standardize on.

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

Sounds reasonable, as long as this is flexible enough to implement the  
behavior needed.

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


As do String, Number, Boolean and RegExp, if I recall correctly.

Regards,
Maciej

Received on Sunday, 27 September 2009 06:29:33 UTC