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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
