Private Names and Methods

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Apr 6 09:01:15 PDT 2012


On Apr 6, 2012, at 5:32 AM, Kevin Smith wrote:

> IOW, OOP-uber-alles does not work and is not necessary in JS.
> 
> Yep - I'm sensing that.

Exclusive OO languages work just fine as do exclusives functional languages.  The pros/cons of each approach and where each may be a better fit could be the topic of a interesting, not not particularly essential conversations. 

The issues we are addressing in this thread and in general as ES programmers is how to be most effective in a hybrid language that offers both OO and functional constructs. We can try to stick to a pure OO subset or a pure functional subset, but in practice  we are typically either forced or find benefit in using both styles within most programs.

> 
> Actually, I'm trying to push the "class" idea to see where it breaks down, and I think my original point still stands:   "methods with private names" and OOP-style "private methods" are not the same thing.

A point that I've been trying to consistently make is that "method" is an OO concept.  It is is a behavioral member of an object and is invoked in a specific manner that emphasizes the object. A method isn't just any function whose first formal parameter is named "this" or"self". If a "method with private names" is not "OOP-style" then we should be calling it a "method" and shouldn't be talking about other OOP characters such as invocations that explicitly distinguished "this" value.

However, I don't believe your original point is at all correct.

To start, it is worth noting that "private method" is not even a concept that existed in the languages that the OOP-style emerged from. Originally all methods were "public".  Over-time emerged recognition of the desirability of clearly labeling  the public protocol (ie interface) of an object as distinct from its "private" implementation details (including the private procedural decomposition of public methods). This was originally done via tools and documentation conventions, not via language enforcement. Second and third generation OOP languages (eg, Eiffel, Java) explored various linguistic  mechanisms to control from where  "private methods" could be observed and invoked.  But they didn't change anything about the method-ness of "private method" .  They were still tightly associated with objects (via class definitions) and their invocation still involves a distinguished "this" value.  The only thing that "private" changed was which source code regions of a program had visibility of the existence of "private methods".

This is exactly what "private name" properties do in ES. They can be used to control the visibility of a property of an object.  That's all.  If you accept that a function-valued property of a ES object directly corresponds to a OO method (and my position is that some do and other don't) then whether the property has a private or string name should have to relevance to that correspondence.

> 
> More to the point:  it seems that given the inability of privately named methods to fully emulate OOP-style privacy, it would seem unlikely that we'd ever want a "private" method modifier, as in:

But I don't think you've demonstrated that inability (or defined what you mean by "OOP-style privacy").

You original post related to a "generic method" that you wished to dynamically exist as a method on multiple, otherwise unrelated, objects.  This isn't even something that could be accomplished in most OOP languages without resorting to the metaprogramming/reflection layers of the language.  I think I demonstrated in my first reply that if you did that in an exclusively OO language you would run into the same issues that you think you see in ES. (In other words, have you tried to do what you are described in Java?).


> 
>     private M3() { ... }
> 
> It would just be too confusing.
> 

You would need to define your intended semantics, but assume this just means that M3 is a private name scoped to a class definition then I don't see why this would add additional points of confusions. 

I think your confusion probably comes from focusing too closely on the intersection between the OOP and functions aspects of ES.  This can indeed  be potentially confusing territory.  I think for new features we should try to keep those aspects of ES as distinct as possible.  For example, that is why I'm so opposed to any sort of optional "this" formal parameter for arrow functions. 

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


More information about the es-discuss mailing list