time to trim mustache

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Jun 1 00:26:03 PDT 2012


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120601/7b7093b5/attachment-0001.html>


More information about the es-discuss mailing list