On Thu, Dec 16, 2010 at 5:24 PM, David Herman <dher...@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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
