Private names use cases
allen at wirfs-brock.com
Tue Dec 21 10:20:01 PST 2010
On Dec 21, 2010, at 9:03 AM, Mark S. Miller wrote:
> On Mon, Dec 20, 2010 at 9:21 AM, Allen Wirfs-Brock <allen at 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":
> 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 (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.
Even if this style did become the norm, I don't see why you would argue in support of mechanisms that allow extension of frozen objects. Isn't the whole point of freezing to prevent any extensions. why is the fact that the extension is accomplished using a side-channel any more acceptable to you.
> 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.
If you don't care about syntactic support for information hiding than we already have solutions. Ephemeron tables provide a side-band mechanisms for dynamically associating additional state with an objects. You have demonstrated one way to do that in your soft fields proposal. Even without Ephemeron tables, it is already possible to hide state within an object using closure capture.
> It seems both of your key points in this message support soft fields over private names.
I don't think you even addressed my first point and your argument concerning the second point is based upon an assumption that I don't share regarding a particular "defensive programming" style.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss