New private names proposal

[David Herman]

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. 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.

But let's please not battle over specification mechanism, especially not in this phase of design. 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. 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?

Remember, the real enemy is the Romans:

    http://www.youtube.com/watch?v=gb_qHP7VaZE

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

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