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 https://github.com/tobeytailor/def.js/. > 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: > obj.foo = 1; > obj.bar = 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 ;-). /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
