Using monocle mustache for chaining.

Brendan Eich brendan at
Sat Nov 12 11:48:26 PST 2011

On Nov 12, 2011, at 9:48 AM, Allen Wirfs-Brock wrote:

> On Nov 11, 2011, at 5:22 PM, David Herman wrote:
>> On Nov 11, 2011, at 4:18 PM, Rick Waldron wrote:
>>> Dave, if nesting were out of the question and monocle-mustache operator always looked like an object literal as they currently exist, would it still be as vile? With that form, I'm a big fan.
>> I'm of multiple minds (a condition I'm gradually getting accustomed to).
>> 1) I'm really against the current syntax, because it hides the fact that it's a mutation. Assignments masquerading as declarative forms bring out Angry Dave (you wouldn't like me when I'm angry...)
> It's not clear that it hides mutation any more than ++x

Well-known C idiom.

> or even +x (in the later case where the value of x in an object with a valueOf method that mutates the object).

Oh come on -- any such mutating valueOf is abnormal in the extreme, a stunt a la

> In general, you have to know what syntax means to understand it.  .{ is new syntax that is defined to mean mutation.  It isn't masquerading as anything.

That's the counter-argument: new idiom. JS is a bit mature to be adding such things. Part of the "Grawlix" immune system reaction is not just to Perl-ish line noise -- it's to new idioms that do not build on existing forms so as to support intuition about meaning. In that light, .= is much better (private name issue aside).

>> 2) I like it better if it includes "=" in it, e.g.:
>>    obj .= { foo: 1, bar: 2 };
> = really isn't right either  because 
>   obj.={foo:1,bar: 2};
> definitely would not mean the same thing as:
> = 1;
> = 1;
> The former does [[DefineOwnProperty]] and allies all the object literal static and dynamic semantics.  The later is just a sequence of [[Put]]s.

Right. .= is not exactly right either.

Some wanted += but it's "taken" (by conversion to string or other primitive and + in the expansion), at least pending user-defined operators.

> I've suggested
>   obj.+{foo:1,bar: 2};
> as a possible alternative if people really want a stronger lexical distinction.

No intuition aids there -- if we do a new idiom, let's minimize it as you have, to .{ without a + in the middle (which is misleading at best).

>> 4) Allen has pointed out that this is problematic for private names. For many use cases, it'd be fine if .= just didn't copy any private names -- done. But Allen's class pattern wanted to be able to specify private names. So he restricted the RHS to look like a literal.
> .{ would be useless if it did not propagate private names.  Also, if it did not do super binding any all the other static and dynamic semantics of object literals.

The motivating use-case for all that, IINM, is the classless class-as-sugar pattern, which I think is not enough to kill classes. If we do classes, what .{ use-cases remain?

>> 5) Still, I have to say, the restricted RHS just seems ad hoc and unsatisfying.
> It's essential for the only use case I care about.

For the classless classes-as-sugar pattern? Enquiring minds want to know ;-).


More information about the es-discuss mailing list