On Dec 16, 2010, at 4:44 PM, Mark S. Miller wrote: > This does *not* mean soft fields and private names are mutually exclusive and > locked in some "there can be only one!" Highlander contest. > > I'll address this last point first, since this seems to be the core issue. > The question I am raising is: given soft fields, why do we need private > names? I translated your examples to show why I see no need for the latter. > If we don't need them, we shouldn't add them.
This reasoning is backwards. *If* we decide the use-cases motivating private names, including usability: both lexical bindings consulted on the right of dot, and as first-class generated values in expressions, are worth supporting, then we will support the private names proposal -- however specified. (If we do decide to support these use-cases with anything like the proposed observable syntax and semantics, then I'm strongly in favor of the specificatiion approach in Allen's writeup, and strongly against the frankly obscure and tortured specification on top of soft fields that you've used.) *If* we decide to support soft fields as a library on top of weak maps, or (it's already in harmony:proposals) just assuming weak maps, then soft field use-cases have their day in the sun via library code (standardized or not). But this has nothing to do with private names as proposed! > Really, it's starting to feel like "Survivor" or "American Idol" around here. > The apples to oranges death-matching has to stop. I want to change the channel. Reasoning backwards from assumed conclusions and overcomplicated translations is not the way to proceed here. We need to agree on use-cases and address usability, not start with an executable spec and stretch it to cover (grudgingly) other applications. I also doubt that soft fields beat private names from any optimizing implementor's point of view (I wear that hat still myself, but I'll defer to full-timers). We really need to consider what users will see, how they'll use the proposed factility, what ends it serves in its untranslated form, and go from there. Anything else is overcomplicated and courts over-specification. /be
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
