On Mon, Dec 20, 2010 at 9:21 AM, Allen Wirfs-Brock <al...@wirfs-brock.com>wrote:
> I've seen mentions in the recent thread that the goal of the "Private > Names" proposal was to support "private fields" for objects. While that may > be a goal of some participants in the discussion, it is not what I would > state as the goal. > > I have two specific use cases in mind for "private names": > 1) Allow JavaScript programmers, who choose to do so, to manage the direct > accessibly of object *properties*. This may mean limiting access to > methods of a particular instance, or to methods of the same "class", or to > various friends or cohorts, etc. > 2) Allow third-party *property* extensions to built-in objects or > third-party frameworks that are guaranteed to not have naming conflicts > with unrelated extensions to the same objects. > > Of these two use cases, the second may be the more important. > I'm glad you agree. By incremental fiddling, such as repairing the encapsulation leaks of private names, perhaps we could brings these two proposals closer together to try to find common ground. However, this second use case would still be a real difference. < http://wiki.ecmascript.org/doku.php?id=strawman:names_vs_soft_fields#conflict-free_object_extension_using_soft_fields> uses your example of this use case. In light of your message, I just added a note on the crucial difference: For defensive programming, best practice in many environments will be to freeze the primordials early, as the dual of the existing best practice that one should not mutate the primordials. Evaluating the dynamic behaviour of Python applications <http://crpit.com/confpapers/CRPITV91Holkner.pdf> (See also http://gnuu.org/2010/12/13/too-lazy-to-type/) provides evidence that this will be compatible with much existing content. We should expect these best practices to grow during the time when people feel they can target ES5 but not yet ES6. Consider if Object.prototype or Array.prototype were already frozen, as they should be, before the code above executes. Using soft fields, this extension works. Using private names, it is rejected. > > Note that I emphasized "properties" rather than a new concept such as > "private fields". I believe we should be trying to build upon the > conceptual foundation of the existing JavaScript object model whenever > possible. We should strive to avoid introducing new concepts such as > non-property fields into the object model. (see > http://www.wirfs-brock.com/allen/posts/43 for further thoughts on this > topic.) > I find this latter point and your elaboration on that web page bizarre. It is the private names proposal that would change the object model, even if you consider these changes minor. The soft fields proposal does not change the object model *at all*. It has the semantics of a side table. It seems both of your key points in this message support soft fields over private names. > > Allen > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
