Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

polettix (7564)

  (email not shown publicly)

Journal of polettix (7564)

Sunday January 06, 2008
08:48 PM

OO and "private" methods

[ #35312 ]

I was writing a couple OO modules and I was struck by a thought about "private" methods. In that quite private context that's my mind, I'm basically thinking of "private" methods as those methods that you don't explicitly support for external usage, but that come handy in your own implementation of a class, mostly for refactoring stuff. So I'm not meaning it in the mainstream OO tongue (like enforcing its usability only within the class), but more on the "intended audience" -- which seems quite in line with Perl's approach.

What made me scared all at once was realising that some derived class could actually override that private method, without explicitly knowing about it! For example, if I have factored out some logic into some "private" method:

sub _get {
   # do stuff

using such a simple sub name, it could well be that someone using my class can implement its own "private" sub _get, and blow it all!

Thinking a bit about this, the solution is obvious. If I want methods that can't be overridden, just stop calling them "methods", and call them just "subs". Which means that instead of:

my $stuff = $self->_get(@whatever);

I have to use:

my $stuff = _get($self, @whatever);

turning OO magic off. Something to remember in the future.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • my $get = sub {
        my $self = shift;
        # do stuff

    # ...

    my $stuff = $self->$get( @whatever );
    • This is brilliant and clean, even if I'd say that I like to leave some space for people to shoot in their own feet, if they're keen to do so. Unless I'm mistaken, the only way for someone to really mess the:

            _get($self, %args);

      is by re-declaring the whole sub:

            no warnings 'redefine';
            sub That::Module::_get {
                  die "with pain";

      which is *way* far from what I consider "fair use of the _
      • Well it’s not really about safety. It’s about namespacing. If you subclass another class, declaring a _get of your own is not safe because you don’t know whether the superclass has declared such a “private” method itself (or will declare one in a future version), and call it using $self->_get and thus accidentally invoke yours instead.

        Using lexicals ensures real encapsulation – not in the sense that you want to keep out people bent on getting in, but in the sense of

        • Uh, now I see: basically you're talking about a case in which my super-class provider hasn't taken the same care as me about his "private" methods. Which makes sense -- I only thought about it the day I posted it!