New private names proposal

Mark S. Miller erights at
Thu Dec 16 17:38:07 PST 2010

On Thu, Dec 16, 2010 at 5:24 PM, David Herman <dherman at> 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 <>,
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

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list