Re^2: Private method variations

[adrianh]

If you want to avoid namespace clashes, you can just avoid the method lookup entirely and pass the object as the first parameter to the private method

This option was mentioned several times in the OP you know :-)

Two problems:

• Using a different calling style makes it harder to switch to/from private/public methods since we have to change the way $self is passed
• The method name is still in the main namespace, so subclasses can call it accidentally leading to potentially odd results

[TimToady]

Nevertheless, it's the use of the same calling style that is the root of the problem.

Perl 6 will have a compromise solution to this. The calling style for a private method is very like, but not quite the same as, the calling style for a public method. All private attributes and method names will start with a distinguishing character, which at the moment I would guess is colon, though at one time it was exclamation mark. Anyway,

has $.foo;            # public attribute
has $:bar;            # private attribute
method foo (){...}    # public method
method :bar () {...}  # private method
...
$self.foo()           # always calls public method virtually
     .foo()           # unary variant
$self.:bar()          # always calls private method
     .:bar()          # unary variant
...
$self.bar()           # calls public bar, not private.

In this way, you don't have to change your argument passing--it's just a matter of inserting an extra character. The calls are also self-documenting, since you can tell by inspection whether you're looking for something public or private. Likewise, any use of $.foo is obviously public, while any use of $:foo is obviously private.

[adrianh]

Perl 6 will have a compromise solution to this. The calling style for a private method is very like, but not quite the same as, the calling style for a public method. All private attributes and method names will start with a distinguishing character, which at the moment I would guess is colon, though at one time it was exclamation mark.

Is this in addition to the submethods mentioned in Apocalypse 6, which seem to solve the same sort of issues?

The self documenting aspect is nice - one of the things I like about Ruby.

(I am so looking forward to A12 :-)

[TimToady]

Is this in addition to the submethods mentioned in Apocalypse 6, which seem to solve the same sort of issues?

Yes. Submethods are for private implementation of a public interface. They're really ordinary public methods that just happen to say "Don't inherit from me, keep looking up the tree for a real method."

By contrast, a private method cannot be called from outside the class. It is, in fact, just a subroutine that the class declares with a syntax resembling method declaration, and that it can call with a syntax resembling ordinary method call, but there's no dispatcher behind the scenes trying to decide which class to dispatch to. It absolutely calls into the current class. If you use the ordinary dot instead, it absolutely goes to the ordinary dispatcher, which totally ignores all private methods, even in your own class.

[duff]

        $self.bar()           # calls public bar, not private.

This seems to imply that you can have both public and private methods/attributes with (almost) the same name. Sounds like trouble to me.

[TimToady]

Gee, you can have scalars and arrays and hashes with (almost) the same name too. Somehow people manage to keep those straight...

Really, I think it's a much worse problem to put public and private methods into the same namespace, because then not only do you have to keep the names straight, but anyone who inherits from you has to keep them straight. Private names should not show up in the public interface at all. Even within the class, it's vitally important to be able to distinguish when you're calling yourself privately from when you're calling yourself through the public interface. C++ style rules just make things completely ambiguous, visually speaking. Drives me nuts.