New private names proposal

[Brendan Eich]

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. No one has denied that soft fields can do *some* of what private names do, but not all, and with observable differences for #.id, reflection, proxies, implementor-friendliness, etc. as we have been discussing.

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!

So even with . as well as [] thanks to this recent page, we still have observable let's say encapsulation differences between the proposals. These are more important than the [] issue, and were more important before 12/12 when my statement you fault as mistaken was in fact correct (going back to Allen's private_names on 12/08 and in most respects going all the way back to the creation of strawman:names) and did count for something in making names / private_names an orange, not a soft-field-implementable apple.

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.

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?


>> And how [] can't be a local transformation, [...]
> 
> Indeed it can't, but I don't see the relevance of that to the
> '"apples to oranges" thing'. We don't know whether [] will be changed
> at all. (In the proposal to add a @ or .# operator, it isn't.)

Way to change the terms of the debate! The wiki proposals put in a bogus elimination contest are the comparable goods here, not some new twist on the mailing list thread.

Specifically, private names does not map a[b] to b.get(a), and no names proposal ever did any such thing. Yet such a transposed .get or .set mapping is observable (by my reading of the several wiki pages Mark has written; please correct me if I'm wrong) in the soft fields proposals, especially the new one you cite which was cloned recently from private_names (if it is indeed a serious syntax for soft fields proposal -- is it? I can't tell).

The proposal to add @ or #. is not anything "ever mooted on the wiki" (unless MarkM just created a new page! He can move fast for a frosty kind of Dr. Freeze villain :-P). It is fine discussion fodder here, but it is *not* relevant to the apples-to-oranges contest being proposed between soft fields and names on the wiki, for many months now.

Dave recently repeated the plea for de-escalating the elimination contest pitting soft fields against private names. That is especially important in light of the moving targets on the wiki and here in the list. Otherwise we'll have various parties reacting to stale information, confusion over what is mooted vs. seriously proposed, and other such confusion. We've already had too much of this.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101223/e341e9da/attachment.html>