On May 31, 2012, at 10:26 PM, David Herman wrote:
> It's become clear to me that mustache syntax is not well motivated. As a
> simple update for objects, there's little it can do that Object.extend
> couldn't do.
Probably not surprisingly, I strongly disagree.
First, WRT motivation. It's motivation is almost exactly that of object
literals. In classic JavaScript, there is nothing that an object literal can
do that can't be done with multiple imperative steps using the new operator,
assignment expressions, Object.defineProperty calls (for accessor properties),
etc. Yet many JS programmer greatly prefer using an object level to describe
construction of a singleton object over using such discrete imperative steps,
In JavaScript: The Good Parts, Crock even lists object literals as one of the
"beautiful features" of JavaScript. The are arguably the best way to describe
singleton objects in JavaScript.
The motivation for mustache is the same but applied to extending the structure
of a pre-existing object in a pleasant and concise manner that does not require
multiple imperative steps. There are many situations where it is necessary to
add a package of properties to a pre-allocated object: defining the properties
for the prototype object that is automatically created for a constructor
function, adding instance specific properties to an instance object within a
constructor; adding constructor properties to a constructor function;
attaching methods to the pure data trees created by JSON.parse, adding client
specific properties to any object returned from a library constructor, etc.
In ES6, with maxmin classes we will also have the need to added instance
properties within a class constructor and to add class-side properties to a
class as these are not currently directly support by the proposed class
definition syntax.
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.
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.
However, when we move into ES6 there are things that we have not yet figured
out how to accomplish with an extends function but which simply fall out of
mustache's design.
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. Object.extend could not see them on the literal
object in order to copy them. Trying to solve this problem by saying that
Object.extend has special reflection privileges would violate the encapsulation
that the non-relection on private name properties was intended to provided. It
would permit any agent to use Object.extend to copy private name properties
(include properties that are intended to server as "type" brands from any
object to any other object.
Anther ES6 specific semantic that has always been part of the mustache proposal
is the correct binding of methods with super references. I've described this
many times. So I'll just describe it again other than to reinforce that
mustache is the great way to dynamically associate super referencing method to
an object without running into the pitfalls that arise with the defineMethod
alternative. I see how with mustache we can live without defineMethld. I don't
see howwithout defineMethod we can live without super binding mustache.
There is strong motivation for mustache and there are important things it can
do that are not currently addressed by any Object.extend proposal that I have
seen.
> I thought with my cascades proposal that it might gain more justification (to
> allow the fluent aka chainable style even for methods that return void
> instead of `this`), but even that's fairly weak tea. And we haven't even
> really discussed what semantics it should have for nested objects: replace
> (aka shallow) or recursively update (aka deep)?
To me, cascades where never an essential use case for mustache. I think
mustache have plenty of justification as originally proposed. I was happy to
explore extending it to encompass the cascade use cases but the fact that those
extensions seem to result in seeming insurmountable issues doesn't relate to
the original unextended mustache proposal.
(BTW, I think the semantics for nest cascades is pretty obvious. But won't
sidetrack on it here).
>
> 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. Object.extend is also not currently
proposed for ES6 so I don't see how you can argue that it is more "on target" .
Finally, to wrap up. I understand that you have a "dead body" hatred for the
".{" syntax. As usual, I'll restate that whileI obviously don't see it that
same way, other syntax variations have always been on the table.
Allen_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
