New private names proposal

[Mark S. Miller]

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 <brendan at mozilla.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101216/9ec161bc/attachment.html>