New private names proposal

[David-Sarah Hopwood]

On 2010-12-24 00:39, Brendan Eich wrote:
> On Dec 23, 2010, at 3:27 PM, David-Sarah Hopwood wrote:
>> On 2010-12-23 21:02, Brendan Eich wrote:
>>> On Dec 23, 2010, at 12:11 PM, Mark S. Miller wrote:
>>> 
>>>> You've said this "apples to oranges" thing many times. I just don't
>>>> get it.
>>> 
>>> You've read the recent messages where it became clear only [], not the
>>> . operator, was ever mooted for soft fields on the wiki.
>> 
>> That's false; the examples at 
>> <http://wiki.ecmascript.org/doku.php?id=strawman:names_vs_soft_fields> 
>> show otherwise.
> 
> You're right, I missed that. Thanks for pointing it out, but brace yourself
> for some push-back.
> 
> The longstanding wiki page (created 08/14) that I was referring to is:
> 
> http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#can_we_subsume_names
>
>  The one you cite is a recent clone (started 12/12) of Allen's examples,
> with translations where possible to soft fields.
> 
> 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. Because of the soft field semantics, the resulting mechanism
provides strong rather than weak encapsulation.

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

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, but without losing the x["id"] ≡ x.id equivalence, and while being
more explicit that this is a new kind of lookup.

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

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

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

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101224/81c02f9c/attachment-0001.bin>