Private Names and Methods

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Apr 6 13:03:04 PDT 2012


On Apr 6, 2012, at 12:18 PM, Kevin Smith wrote:

> As Allen mentioned, I think it would really help if you could show, say, real Java (or C# or C++) code and explain what it can do that JavaScript + private names can’t.
> 
> (Sorry for that double-post, BTW)
> 
> I can't : )
> 
> It's an abstract guarantee.  Private methods (in Java let's say) give me the guarantee that I can refactor at will with them without any externally visible changes.  Privately named methods in JS do not.
> 
> Look at it this way:  if I have a method that looks like this:
> 
>     private helperMethod() { ... }
> 
> and it's called from another method like this:
> 
>     toString() { this. at helperMethod(); }
> 
> someone coming from Java or C# is going to expect a nonvirtual method invokation.  See the Java spec for details [1].  OK - everything is dynamic in JS, so they're just "confused", right?  Why even invite that confusion with misleading syntax?

Of course, anyone coming from a dynamically typed OO language is going to think "virtual method invocation" (except probably not using those words) because that is essentially the only kind of method invocation you get in a dynamically typed language.

But, I think I now see where you are coming form...

in a reply today to Herby I wrote (emphasis added):
> 
> Keven's original problem statement imposed the requirement that refactoring a method to use a "helper" retained the ability to individually move the method to a different object without moving any associated "private methods".  Such a refactoring can only be accomplished by decomposing the method into lexically bound helper functions rather than dynamically (invocation) bound helper methods.   There is nothing wrong with the sort of decomposition you are referring to.  It just doesn't work for Kevin's problem statement (in any language).


In Java the combination of static typing and private visibility permits this.helper() to be lexically resolved at compilation time even though the call site syntactically looks identical to a virtual method invocation. This permits the refactoring you describe. Semantically this is exactly the same as making the helper be lexically bound function in ES. 

It is primarily an idiomatic difference between programming in a static OO language and a dynamic OO language.  If you do this style of lexically resolved decomposition in ES you actually can use your generic method on a different kind of object, like your original problem statement required.  I don't believe that you can do that with your Java solution.  It its still a type shape mismatch that is gong to have to be detected somewhere (presumably by the java.lang.reflect methods that would be used to transfer or invoke the method).

> 
> "private" syntax isn't a part of the current class proposal, I know.  I'm just trying to think ahead - and to strike at the heart of what a "class" in JS ought to be.

ES is clearly a dynamically typed language rather than a statically typed language.   Whatever JS classes ought to be, they need to be based upon dynamic language concepts.

Allen

> 
> 
> kevin
> 
> [1]:  http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12
> 
> 
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

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


More information about the es-discuss mailing list