OO and "private" methods

polettix on 2008-01-07T01:48:27

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.

---

Or stay out of the symbol table altogether

Aristotle on 2008-01-07T13:37:36

my $get = sub {
    my $self = shift;
    # do stuff
};

# ...

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

Re:Or stay out of the symbol table altogether

polettix on 2008-01-08T22:48:40

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 _get symbol".

Thank you for the suggestion, anyway :)

Re:Or stay out of the symbol table altogether

Aristotle on 2008-01-09T04:47:41

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 preventing unintended interactions.

Re:Or stay out of the symbol table altogether

polettix on 2008-01-09T07:55:58

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!