using Private name objects for declarative property definition.

Brendan Eich brendan at
Fri Jul 8 15:24:34 PDT 2011

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[__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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list