New private names proposal

[Mark S. Miller]

On Fri, Dec 17, 2010 at 10:06 AM, David Herman <dherman at mozilla.com> wrote:

> Let me make a gentle plea for not creating unnecessary controversy. Take a
> step back: we all seem to agree we would like to provide a more convenient
> and performant way to create private fields in objects.
>

Yes. We agree on more here than we disagree on. It is easy to lose sight of
this because we have more reason to talk about the areas where we disagree.
So to make the agreement explicit, yes, "we would like to provide a more
convenient and performant way to create private fields in objects". Exactly.
Thanks.



> In terms of observable behavior in the runtime model, there aren't that
> many differences between your proposed soft fields and the original names
> proposal or Allen's recent revisions. There are a handful of points where we
> have different ideas about what the desired behavior should be, and those
> are worth discussing.
>

Yes. There aren't many, but they are important.


>
> But let's please not battle over specification mechanism, especially not in
> this phase of design.
>

The specification mechanism is not at all central to the controversy from my
side. Were the semantics of soft fields equivalently specified using
your specification
mechanism, I'd be perfectly happy. If that was the main source of
disagreement from your side, perhaps we are closer to agreement than we
thought.

This has come up before verbally, and my position has always been clear and
consistent. For the record: Different spec mechanisms serve different
purposes. In the end, it would be good to have multiple forms of
specifications that we're confident are equivalent. For various reasons, I
prefer to focus on specification by (approximate) self-hosting or desugaring
wherever possible -- it helps me distinguish between new fundamentals vs new
conveniences. For standards process reasons, I understand that only one form
of spec should be normative. I have always made clear that the self-hosted
specification need not be the normative one, as long as we're confident of
exact equivalence



> We shouldn't jeopardize the process over whether it's better to
> conceptualize the feature as storing private fields in a side table or
> internally.
>

Conceptualize for which purpose? For casual use, I think we're again in
agreement. The reason I called them "soft fields" is to emphasize that they
can be conceptualized as storing private fields internally. For
implementation, we're in agreement again. That's the point of the transposed
representation. For formal semantics, I feel strongly that the side table is
the necessary right conceptualization, for all the reasons David-Sarah so
well captured in his message.



> Can we try to stay on track with the Harmony process, where we recognize
> that we have common goals and try to move forward from there and discuss
> individual features as objectively as possible, rather than engaging in
> winner-take-all wars?
>

The issue was never winner-take-all. The issue is all the many problems with
the current names proposal, and my desire to see us avoid these problems. If
we can agree on something as simple, secure, usable, and functional as soft
fields, and with so little contagion across the rest of the spec, I'd be
very happy. I don't care whether this is seen as a successor to current soft
fields or current names. That was never the point.

Regarding the Harmony process, we are staying on track by objecting that the
current names strawman has many problems that some of us consider fatal.
With these fatal issues unresolved, we would violate the process to allow
these to falsely claim consensus and more forward to "proposal". If you see
raising such objections as getting off track, then I'm not sure what you see
as the Harmony process.


> Remember, the real enemy is the Romans:
>
>     http://www.youtube.com/watch?v=gb_qHP7VaZE
>

;)

Thanks for reminding us of our many points of agreement and helping us find
a way forward.


>
> Dave
>
>
> On Dec 16, 2010, at 5:38 PM, Mark S. Miller wrote:
>
>
>
> On Thu, Dec 16, 2010 at 5:24 PM, David Herman <dherman at mozilla.com> wrote:
>
>> Ok, I open it for discussion. Given soft fields, why do we need private
>> names?
>>
>>
>> I believe that the syntax is a big part of the private names proposal.
>> It's key to the usability: in my view, the proposal adds 1) a new
>> abstraction to the object model for private property keys and 2) a new
>> declarative abstraction to the surface language for creating these
>> properties.
>>
>
> As shown on <
> http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields>,
> the syntax you like applies equally well to both proposals. The fact that I
> don't like this syntax is not an argument (to one who does like the syntax)
> that we should do names. Were names adopted, I would still not like this
> syntax and would still argue against it. Were the syntax adopted, I would
> still argue that the syntax should be used to make soft fields more
> convenient, rather than make names more convenient. The arguments really are
> orthogonal.
>
>
>
>>
>>
>>  And I disagree.
>>
>>
>> I'm sorry, but what do you disagree with? That I am raising the question?
>>
>>
>> No, I disagree that the two are in direct competition with one another.
>>
>> Below, you seem to be saying that given names, why do we need soft fields?
>> How is that not a  "there can be only one!" Highlander contest? If that's
>> not what you're saying, then what?
>>
>>
>> It's not what I'm saying. I'm saying that private names are independently
>> useful, and weak maps are independently useful, and given *weak maps* we
>> don't need soft fields. It might have been less confusing if I had left out
>> the latter point. Just to break it down as clearly as possible:
>>
>> - I don't believe soft fields obviate the utility of private names.
>> - I don't believe private names obviate the utility of soft fields.
>> - Given that soft fields are expressible via weak maps, I don't believe
>> they are worth adding to the standard.
>>
>> In fairness, I think the apples-to-apples comparison you can make between
>> the two proposals is the object model. On that score, I think the private
>> names approach is simpler: it just starts where it wants to end up (private
>> names are in the object, with an encapsulated key), whereas the soft fields
>> approach takes a circuitous route to get there (soft fields are semantically
>> a side table, specified via reference implementation, but optimizable by
>> storing in the object).
>>
>>
>>> I happen to like weak maps very much, and very much hope for a world
>>> where ES a) makes it easy to write (any number of) soft field libraries and
>>> b) makes it *easy* to store encapsulated data in objects.
>>>
>>
>> How do names make this easier than soft fields?
>>
>>
>> The syntax (see above).
>>
>
> Ok, how do names with your syntax make this easier than soft fields with
> your syntax?
>
>
>
>>
>> Dave
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101217/dbf5b781/attachment-0001.html>