Private names use cases

[Allen Wirfs-Brock]

See below:

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":
> 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 (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.
> 
> 

Not everybody in the JavaScript community agrees that this style of defensive programming is desirable or should be a "best practice".  On my blog, there was resistance expressed to JavaScript providing any sort of information hiding mechanism. I would not anticipate frozen primordials becoming the norm anytime soon. 

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.


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

I am speaking of the object model, as perceived to by a JavaScript programmer of moderate skill and also by JavaScript implementors.  To me, an incremental extension of a concept that is already present (extending the set of values that can be used as a property name) is a much smaller extension to the object model than the introduction of a new form of per object state (whether called a private field, a soft field, or something else).

The fact that you are proposing implementing you object extension as a look-aside table doesn't mean it isn't a conceptual extension to the object model perceived by JavaScript programmers.  That might arguably be the case if you were simply defining a set of conventions based upon Ephemeron tables for decorating objects with additional non-encapsulated state.  However, as soon as you tie into either the language's property access syntax ( . and []) as you have (perhaps reluctantly) proposed you have extended the conceptual object model.

It seems to me, the real point of difference here is whether or not we should add a syntactic mechanism that supports information hiding in the context of JavaScript objects.  Some constituents want this, others do not. 

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.

However, neither of these mechanisms are integrated with the fundamental concept of an "object" that is defined by the language specification and taught to JavaScript programmers.  They are based upon coding patterns that assume understanding of difficult concepts (Ephemeron or closure capture).  In addition, in the context of current implementations their performance characteristics will be inferior relative to standard property access.  If you care about these issues than you probably fall into the camp that wants some sort of syntactic and semantic language extension that explicitly supports object information hiding.



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


>  
> 
> Allen
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> 
> -- 
>     Cheers,
>     --MarkM

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