At this point, I'll just mention that this response seems overly emotional, filled with name calling, and seemingly disconnected from the case I'm actually making. (For example, I never said that soft fields would be more or as efficient as names. Merely that, if primitive, they could benefit from the same representation you are considering for names. As a library, they cannot be close to that efficient.) I'll wait till I see a calmer and more reasoned response to what I'm actually saying, rather than (in the pejorative sense) straw men.
On Thu, Dec 16, 2010 at 4:54 PM, Brendan Eich <[email protected]> wrote: > 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 > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
