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