time to trim mustache

[David Herman]

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