Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
mjs at apple.com
Sun Sep 27 02:57:41 PDT 2009
On Sep 27, 2009, at 12:30 AM, Brendan Eich wrote:
> On Sep 26, 2009, at 11:28 PM, Maciej Stachowiak wrote:
>>> 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.
> ES3 lets host objects choose "function" or "object" or any old
> string ("Implementation-dependent").
> ES5 says:
> Object (native or host and does implement [[Call]])
> -> "function"
> Object (host and does not implement [[Call]])
> -> Implementation-defined except may not be "undefined", "boolean",
> "number", or "string".
I think it may be a compatibility risk for HTMLCollection to report
its type as "function" instead of "object".
>> 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.
> Right, thanks for clarifying that. DOM collection types, even if
> callable (VBScript was to blame) are not function objects, and DOM
> constructors, unlike chapter 15 built-in ES constructors, are not
> generally function objects.
>>> 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.
> Why not for HTMLFormElement? Agree for HTMLCollection.
By HTMLFormElement I mean the actual instances that represent the
<form> element in an HTML DOM, not the pseudo-constructor object named
"HTMLFormElement" on the window object. HTML5 gives it callable
indexing. It already inherits from HTMLElement (and Element and Node)
so it's unclear how to stick Function into its prototype chain. And I
don't think we want call(), apply() and bind() methods to start
appearing on form elements.
>> 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.
> See http://wiki.ecmascript.org/doku.php?id=strawman:catchalls but
> note objections there, as well as some alternatives discussed in es-discuss at mozilla.org
Thanks for the reference. That does look similar to my suggestion.
However, it looks like the "invoke" and "construct" methods there are
intended for calling a property of the object (or invoking it as a
constructor), rather than for applying call or construct to the object
> A MOP for catchalls that stratifies the hooks into mirage (by
> analogy to mirror-based reflection) objects may be forthcoming;
> we'll see (I'll let the experts say more). A dark horse, at this
> point, but hey, those other horses made it out of the barn ;-).
> For simple things like non-constructor functions one might prefer a
> declarative form. As an implementor and a developer, I would --
> mutation is a bitch to optimize in a VM, and to contain in one's
> "user code". Also the meta-programming API seems likely to be more
> verbose than the (still elusive, but stipulate that it must be
> concise) hypothetical declarative syntax.
Sure - one way a MOP approach helps is by moving past debates about
the most elegant syntax, by having unapologetically inelegant syntax.
Then maybe once the capability is there, someone can invent good
>>> 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.
> Me too, except if I had to do it all over again I would have worked
> harder to make function-ness orthogonal to prototype, a mixin if you
I wish functions and constructors were different kinds of things. I'm
not sure if that's the same kind of idea you're talking about.
> At this point,
> takes away the need to inherit .apply/call, leaving bind as
> something that might better be a primitive operator that works for
> all callables.
> I'm musing a bit here, bear with me. If we only hack incrementally,
> and preserve backward compatibility with frankly dumb (or merely
> hasty) design decisions (many mine!) then we'll probably make less
> progress than if we try to rationalize old and new in a better
> systematic design.
That's a little too abstract for me to tell if I agree or not.
> So I too am indifferent so long as we do make progress factoring
> function-ness out of which-prototype, if you get what I mean.
>>> Date needs the latter.
>> As do String, Number, Boolean and RegExp, if I recall correctly.
> Indeed. More warts to avoid generalizing into a complexion. :-/
It doesn't seem that crazy to me to have different call and construct
behavior, though the differences in these cases may be confusingly
More information about the es-discuss