New private names proposal

[Brendan Eich]

On Dec 23, 2010, at 5:17 PM, David-Sarah Hopwood wrote:

> On 2010-12-24 00:39, Brendan Eich wrote:
>> Since the new page is a clone of Allen's private_names strawman, of course
>> it clones the "private x" examples and shows . and :-in-literal being
>> used.
>> 
>> It's not clear how this new page helps eliminate private_names as a
>> proposal.
> 
> What it does is adapt the private_names syntax to inherited explicit soft
> fields, exactly as it claims to do. That removes a lot (not all, since some
> is associated with the syntax) of the specification complexity from that
> proposal.

We don't agree on specification complexity.


> Because of the soft field semantics, the resulting mechanism
> provides strong rather than weak encapsulation.

We don't agree on strong always winning.

Therefore "it's not clear how this new page helps eliminate private_names."

If you and MarkM were the dynamic duo of TC39, or 2/3rds of a troika, it would matter. But that's not how the committee cookie crumbles. Also, it's not obvious from all the comments on es-discuss that everyone is on board for strong encapsulation absolutism (and I do mean that, not as an insult).

Really, there's a deeper disagreement here than over syntax mapped to a subset of semantics.


>> Note in particular the place in this new page where Mark does not create a
>> polymorphic property access function:
>> 
>> "Enabling the use of [ ] with soft fields requires the kludge explained at
>> can we subsume names. If we can agree that this polymorphism does not need
>> such direct support, ...."
>> 
>> We cannot agree, that's the point! Orange, not apple, wanted and proposed
>> by private names. Polymorphism wanted. Difference!
> 
> It is not "comparing apples and oranges" to suggest that a specific
> subfeature might not be worth its complexity. The phrase "comparing apples
> and oranges" specifically refers to comparing things that are so different
> as to be incomparable.

We seem to have much DNA in common with other critters. So too with apples and oranges. The point stands: soft fields and private names are not equivalent, observationally and otherwise.


> Note that the polymorphism referred to (being able to look up either a
> private name or a string property) is also achieved by the @ or .# operator
> approach,

Irrelevant on TC39's January agenda, which is where the elimination-contest was aimed.


> but without losing the x["id"] ≡ x.id equivalence, and while being
> more explicit that this is a new kind of lookup.

Great, the debate continues in es-discuss.

BTW, sigils suck (Allen's refactoring point).

This settles nothing, but I agree with Dave et al. on the champions model trumping design-by-committee or design-by-mailing-list.


>> So even with . as well as [] thanks to this recent page, we still have
>> observable let's say encapsulation differences between the proposals.
> 
> Of course, that's the main reason why I favour the soft fields semantics,
> because it provides strong encapsulation.

Guess what? It's not all about *you*. :-|


>> Moreover, since you are citing a recently added page, and (below) also
>> adducing mere es-discuss sketching of novelties such as @ as somehow moving
>> the proposals forward, even though @ has not yet been proposed in the wiki,
>> I argue that fair play requires you to keep current in all respects: we
>> proponents of both weak maps etc. *and* private names have argued recently
>> that soft fields should *not* have syntax looking anything like property
>> access.
> 
> Yes, I know. I don't know why you are determined to paint me as having
> some kind of ideological dispute with the proponents of private names,
> as opposed to merely having strong technical objections to that proposal.

I never said "ideology", you just did. I did say you were selective in your application of recency or currency in framing the debate. Respond to that, please.


>> Shifting the terms of the debate mid-conversation (across recent weeks,
>> with new pages alongside older ones, and new messages in the list) cuts
>> both ways.
>> 
>> Our rejection of property syntax for soft fields makes this whole "map one
>> (subset, in the case of private names) syntax to two (subset, in the case
>> of private names) semantics" argument obsolete, at least when it comes to
>> property access syntax. So, can we move past this?
> 
> Yes, please! (I barely have any idea what you're talking about when you
> refer to "shifting the terms of the debate". Isn't that just adapting to
> the current context of discussion?)

No, as you allowed in replying to Dave Herman about your misuse of "proposal". The wiki.ecmascript.org process feeds into TC39. The es-discuss chatter does not, except by members of the committee championing ideas from the list (which I support, obviously, where the ideas are worth considering). The ideas from the list need to turn into wiki strawman proposals to get further.

/be