On Jun 1, 2012, at 12:26 AM, Allen Wirfs-Brock wrote:
> These can (and now are) all done in multiple imperative steps. Mustache
> allows all of these sorts of object extensions to be accomplished using the
> exact same beautiful object literal syntax.
A beautiful syntax for something that can be done with a single function call
an an object literal is *very* weak motivation. Syntax isn't cheap. I probably
need to write a blog post about this. For syntax to be worth adding, it has to
clear a higher bar than API's. If we can write an API that does something
perfectly well and a new syntax only saves a handful of characters, it's not
enough.
> Of course you can argue that, you would get the same thing via an
> Object.extend function with an object literal passed as an argument. On a
> purely functional basis, that is true, for ES5 level semantics. However, I
> argue that this lacks the concise beauty of mustache.
An analogy: you could say the same thing about keyword arguments; writing
f(width: 320, height: 240)
is arguably more beautiful than
f({ width: 320, height: 240 })
because the language is saying exactly what you mean without need for
boilerplate. But that boilerplate is only two characters, so it's not worth the
additional language complexity to add support for it. Another analogy:
Smalltalk gets along great with using blocks for control abstractions because,
again, it's only two skinny little characters of boilerplate.
> One of these things is installing private named properties upon an existing
> object. As currently specified, those could not be communicated to an extend
> function via an object literal because we have disallowed any form of
> refection upon private named properties.
We dropped computed property names in object literals, so we don't even have
any way of putting private names on an object literal anyway. The sets of
things that you could express with mustache but not with Object.extend is fast
dwindling for ES6.
>> This debate over mustache/cascade/etc just isn't a worthwhile use of time.
>> And it's not on target for ES6 anyway. It's time to set this aside and just
>> focus on standardizing an Object.extend API (or possibly two, one for
>> shallow, one for deep).
> Worthwhileness is simply your opinion, not mine. Anything we collectively
> decide we need in ES6 can be in ES6.
Mustache was demoted to strawman. Proposals in strawman are not accepted for
ES6. We can certainly break our own process if we need to, but it provides a
useful check on moving too fast. If there's anything we should be careful
about, it's new syntax. Again, I need to write a blog post about this.
> Object.extend is also not currently proposed for ES6 so I don't see how you
> can argue that it is more "on target" .
It's not. We can certainly *discuss* things that are not on target for ES6, and
I claim that Object.extend is something that would be of more value for us to
discuss now, because as soon as we come to some agreement, developers can
polyfill it and use it immediately. We should pave that cowpath because it's
the more immediately solvable problem, regardless of whether it ends up in ES6.
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
