Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
brendan at mozilla.com
Sun Sep 27 11:28:34 PDT 2009
On Sep 27, 2009, at 2:57 AM, Maciej Stachowiak wrote:
>> 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 itself.
The discussion (the thread started here:
) brought out this and other points. Having to reify an object as a
property value, only to invoke it somehow (call or construct), often
makes excess garbage, hence this proposal's call-property and
But your point is good too: sometimes you already have an object and
it needs to act as a callable or constructor.
A mirage-based dark-horse candidate proposal will (I hope) deal with
>> 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 syntax later.
Preferably before anything is prematurely standardized...
>> 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 will.
> 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.
I said that at ICFP 2005 in answer to a question (from Simon Peyton-
Jones, IIRC), so I agree.
But beyond separating functions from constructors, the ability to
spread array elements as positional actual parameters, and to deal
with |this|-binding separately for functions, help to untangle the
multiple strands of magic woven into function objects in ES so far.
Combining constructors and functions is not the only case of unwanted
>> 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.
Shortest-path evolution can walk uphill only a little bit at a time,
and get stuck at local minimal points in a design space, when over the
big hill is a much better, richer valley to evolve in. This path
dependency problem bits many real-world systems.
I experience this point as hard and painful, like concrete -- it' s
not abstract. I've been around too long to ignore it, as it's all
around us on the web, and it has been since 1994 if not earlier.
Compatibility concerns in the form of graceful degradation or
progressive enhancement are not unmixed blessings. More coherent
stacks from Microsoft, Adobe, and Sun can rightly claim to solve
problems more cleanly and simply than the web. Of course these stacks
have other problems, mainly from being single-sourced if not
proprietary, but also from not progressing compatibly, and for other
reasons I won't digress on.
But there's no point pretending the Web (ES, DOM, etc.) is an example
of a well-designed toolkit for building user-facing distributed apps!
More information about the es-discuss