New private names proposal

[David Herman]

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


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

Dave

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