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.@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
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
