On Jul 8, 2011, at 2:43 PM, Andreas Rossberg wrote:
> One minor suggestion I'd have is to treat names as a proper new
> primitive type, i.e. typeof key == "name", not "object". That way, it
> can be defined much more cleanly what a name is, where its use is
> legal (as opposed to proper objects), and where it maybe enjoys
> special treatment.
We went back and forth on this. I believe the rationale is in the wiki (but
perhaps in one of the strawman:*name* pages). There are a couple of reasons:
1. We want private name objects to be usable as keys in WeakMaps. Clearly we
could extend WeakMaps to have either "object" (but not "null") or "name"
typeof-type keys, but that complexity is not warranted yet.
2. Private name objects are deeply frozen and behave like value types (since
they have no copy semantics and you can only generate fresh ones). Thus they
are typeof-type "object" but clearly distinct from string-equated property
names that JS has sported so far.
In other words, we don't gain any distinctiveness, or make any particular
claims about private name objects that could not be made about other
(deeply-frozen, generated-only, say by Object.create or Proxy.create in a
distinguished factory function) kinds of objects, via a new typeof-type.
In light of these points, making private names be "objects" in both the
as-proposed WeakMap sense, and the typeof-result sense, seems best.
So, while we have added "null" as a new typeof result string, and we have
considered adding other novel typeof results, and we believe that we can add
new typeof results with good enough reason (thanks to IE adding some
non-standard ones long ago, and programmers tending to write non-exhaustive
switch and if-else "cond" structures to handle only certain well-known typeof
cases), in the case of private name objects, we don't think we have good enough
reason to add a typeof name -- and then to complicate WeakMap.
>> Point = {
>> //private members
>> [__x]: 0,
>> [ __y]: 0,
>> [__validate](x,y) { return typeof x == 'number' && typeof y =
>> 'number'},
>> //public members
>> new(x,y) {
>> if (!this[__validate](x,y)) throw "invalid";
>> return this <| {
>> [__x]: x,
>> [__y]: y
>> }
>> };
>> add(anotherPoint) {
>> return this.new(this[__x]+another[__x], this[__y]+another[__y])
>> }
>> }
>
> I like this notation most, because it can be generalised in a
> consistent manner beyond the special case of private names: there is
> no reason that the bit in brackets is just an identifier, we could
> allow arbitrary expressions.
Then the shape of the object is not static. Perhaps this is worth the costs to
implementations and other "analyzers" (static program analysis, human readers).
We should discuss a bit more first, as I just wrote in reply to Allen.
> So the notation would be the proper dual
> to bracket access notation. From a symmetry and expressiveness
> perspective, this is very appealing.
It does help avoid eval abusage, on the upside.
Proceeding bottom-up, with orthogonal gap-filling primitives that compose well,
is our preferred way for Harmony. Private name objects without new syntax,
requiring bracket-indexing, won in part by filling a gap without jumping to
premature syntax with novel binding semantics (see below).
Here, with obj = { [expr]: value } as the way to compute a property name in an
object initialiser (I must not write "object literal" any longer), we are
proceeding up another small and separate hill. But, is this the right design
for object initialisers (which the normative grammar does call
"ObjectLiterals")?
> Notation-wise, I think people would get used to using brackets. I see
> no good reason to introduce yet another projection syntax, like @.
Agreed that unless we use @ well for both property names in initialisers and
private property access, and in particular if we stick with bracketing for
access, then square brackets win for property naming too -- but there's still
the loss-of-static-shape issue.
> Whether additional sugar is worthwhile -- e.g. private declarations --
> remains to be explored. (To be honest, I haven't quite understood yet
> in what sense such sugar would really be more "declarative". Sure, it
> is convenient and perhaps more readable. But being declarative is a
> semantic property, and cannot be achieved by simple syntax tweaks.)
Good point!
The original name declaration via "private x" that Dave championed was
definitely semantic: it created a new static lookup hierarchy, lexical but for
names after . in expressions and before : in property assignments in object
literals. This was, as Allen noted, controversial and enough respected folks on
es-discuss (I recall Andrew Dupont in particular) and in TC39 reacted
negatively that we separated and deferred it. I do not know how to revive it
productively.
/be_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
