Thanks for filling in those blanks -Rick
On Wednesday, May 23, 2012 at 7:43 PM, Brendan Eich wrote: > Rick, thanks for taking these. I'll try to add a bit of explanation > where it looks like "you had to be there" ;-). > > /be > > Rick Waldron wrote: > > # 4.10 Object.observe (Rafeal Weinstein) > > > > Rafeal Weinstein: > > - Introduction to proposal > > > > See: http://wiki.ecmascript.org/doku.php?id=strawman:observe > > > > MM: > > - In favor of spec'ing an event loop > > > > > BE: let's subset the parts of Hixie's HTML5 spec that we need, and no > more (and reference that spec so it's likelier we keep the subset relation). > > > > AWB: > > - There is too much going on at low level with this proposal > > > > > Allen's point was that all of the strawman champions and Allen, the spec > editor, and experts and interested folks (Tom Van Cutsem, people on > es-discuss) all need to digest the non-local effects of the local but > low-level changes in the strawman. > > I said this, and also offered that we would prototype in SpiderMonkey > alongside V8. > > > RWeinstein: > > - Asking for blessing to prototype in v8: approved. > > > > > I emphasized that all strawman not moved to deferred: namespace in the > wiki (and there's a curation process here, which can fail sometimes) are > fair game for prototyping. > > > Property Assignment Shorthand > > Rather, "Object Literal" or "Property Definition" (in ES3, > PropertyAssignment) shorthand. > > > eg. > > function point(x, y) { > > return { x, y }; > > } > > > > { x: x, y: y } > > > > This is too unclear > > w/r to destructuring: both, or nothing. > > Plenty of opposition based on clarity. > > > > Resolution: Nothing, no change. > > That is, we keep the shorthand for *structuring* as well as for > *destructuring* where it is clearly useful. > > LH observed that the 90%+ by frequency use-case for destructuring wants > the shorthand, whereas for structuring (making an object via an object > literal expression) it's more like 10% or 1%. BE agrees but BE and MM at > least want duality consistency: shorthand for both literals and patterns. > > That's where we left ES6. > > I personally think the "n00bs will see the new shorthand and > artificiailly declare variables of the same name as the property just to > use the shorthand" worry as an undemonstrated speculation, and too > fearful. We need user-testing evidence of this! > > EA raised the other interpretation of {x,y} in an expression, as a > WebIDL-ish enum equivalent to {x: "x", y: "y"} -- for making string > manifest constants named by the string contents -- but this is a > different semantics, and rarer yet than {x,y} to make a point from x and > y bindings. > > AR mentioned future-hostility to set notation in JS. BE ack'ed that, > figures it is un-possible given object literals being wrapped in curlies > anyway. > > > Triangle > > > > Is capable of giving up private names > > > > If people have __proto__ they will not use <|. > > > > MM: > > - From a security perspective, I'd like to move __proto__ out of annex > > B and into normative body > > > > BE: > > - If MS puts __proto__ in IE, then it becomes defacto standard and we > > might as well put it in the standard. > > > > 1. __proto__ > > 2. grawlix > > > > > > Resolution: Indefinite postpone\ > > I.e., we defer/cancel triangle and go with normative mandatory > __proto__. W00t! Kidding, mostly, but I perpetrated it, it is in all > browsers but IE, and IE feels the heat on mobile (thank you Thomas > Fuchs!). So __proto__ is the winner already, we're just trying to > forestall the inevitable. > > > Moustache > > > > o.{ p: v } > > > > BE: > > - Propose that moustache is kept, but still consider Object.extend > > > > MM: > > - Would like to consider both moustache and Object.extend > > > > > > How about… both? > > = assign > > : define > > > > ie. > > > > o.{ > > p1: "to define", > > p2 = "to assign" > > }; > > > > > Further choice: allow = instead of : in object literals too, not just in > mustache-literals! > > > Positions: > > > > Just Define > > Just Assign > > Both Define and Assign > > Alone > > Applied to object literals > > > > > Ah, you got that one. Thanks. > > OH worried that the JSON theft attack (a global setter targeting > well-known id in top-level JSON blob) would work, but this requires both > = instead of : in the JSON blob, and the wrong MIME type for loading > JSON as a <script>. > > > Resolution: Return to strawman for revision, needs own wiki page. > > I still want mustache. My advice was to copy and lightly mutate the > ObjectLiteral grammar instead of reusing it, to allow = and : as > alternatives for assign and define, respectively; and for any other > reason. Sometimes pattern languages diverge from expression grammars for > good reason. > > > Computed Keys > > > > Erik Arvidsson: > > - Today, properties are static and knowable, computed keys are not > > knowable. > > > > Resolution: Deferred. > > But just to capture all the nuance, the idea of @privateName: value in > an object literal has support and maintains the compile-time name > structure that EA rightly cited. > > The [anyExpr]: value idea for a property definition in an object literal > is what I believe died today. If you want to extend an object with a > computed property name, use assignment or Object.defineProperty. > > > # Weak Refs > > > > Yehuda Katz: > > - Use case: observers > > > > > > Resolution: Continued, due to lack of time. > > BE: valid use-case for observers, virtualization layers, other such > bridging functions. MM/AWB need to discuss more, ideally here on es-discuss! > > > > # Value Objects > > > > Brendan demos, explanation of the implementation and operator overloading > See https://bugzilla.mozilla.org/show_bug.cgi?id=749786 and stay tuned. > > Thanks again, Rick! > > /be
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
