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

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

https://mail.mozilla.org/pipermail/es-discuss/2009-May/009168.html

) 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  
construct-property hooks.

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


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


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

/be

Received on Sunday, 27 September 2009 18:42:34 UTC