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