using Private name objects for declarative property definition.

Andreas Rossberg rossberg at google.com
Sat Jul 9 00:48:47 PDT 2011


On 9 July 2011 00:24, Brendan Eich <brendan at mozilla.com> wrote:
> 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.

I can see that being a relevant use case for weak maps. But the same
logic applies to using, say, strings or numbers as keys. So isn't the
right fix rather to allow weak maps to be keyed on any JS value?

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

> Oh, of course you meant to distinguish private names via typeof precisely to tell that they are not converted to strings when used as property names. For that test, the proposal
>
> http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects
>
> proposes an isName predicate function exported from the "@name" built-in module.

Yes, I know. But this is introducing a kind of ad-hoc shadow type
mechanism. Morally, this is a type distinction, so why not make it
one? Moreover, I feel that ES already has too many classification
mechanisms (typeof, class, instanceof), so adding yet another one
through the back door doesn't seem optimal.

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

Why do you think that it would that make WeakMap more complicated? As
far as I can see, implementations will internally make that very type
distinction anyways. And the spec also has to make it, one way or the
other.

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

I don't think that the more general form would be a big deal for
implementations. And it is still easy to identify object expressions
with static shape syntactically: they don't use [_]. Analyses
shouldn't be harder than for a series of assignments (which you
probably could desugar this into).

> 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")?

(If you care about that, then that's a misnomer already, since the
property values have always been arbitrary expressions.)

Thanks,
/Andreas


More information about the es-discuss mailing list