in reply to Re^2: Private method variations
in thread Private method variations

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.

[download]
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.

Replies are listed 'Best First'.
Re^4: Private method variations
by adrianh (Chancellor) on Mar 01, 2004 at 22:11 UTC
    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 :-)

[reply]
      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.

[reply]

        So why would I ever prefer to use a submethod over a private method? This might just be my brain at 1:30am but I can't see a use case that submethod fits better than a private method.

        Any chance of enlightenment or should I just wait for A12/E12 :-)

[reply]
Re: Re: Re^2: Private method variations
by duff (Parson) on Mar 01, 2004 at 20:58 UTC 
            $self.bar()           # calls public bar, not private.

    [download]

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

    duff

[reply]
[d/l]
      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.

[reply]

In Section Meditations