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
