ennuikiller has asked for the wisdom of the Perl Monks concerning the following question:

I'm using Damian Conway's "inside-out" objects as described is his wonderful book Perl Best Practices to construct an object-oriented interface to a security system at my client. I'm coming across the need to use internal helper methods within my module that I would normally designate as "_some_method". However, this seems to break encapsulation since they can be called directly via the package name. Is there any way of making these methods truly private? As an example, 
use SOD::MyOOInterface;

my $instance1 = SOD::MyOOInterface->new();
$instance1->_some_method;  #this produces an error: 
SOD::MyOOInterface::_some_method;   # this results in a successful met
+hod call

[download]
obviously I dont wnat the direct call of _some_method to succeed. Is there any way of guaranteeing this? Thanks in advance! perl object-oriented private-methods

Replies are listed 'Best First'.
Re: perl OO private methods
by merlyn (Sage) on Nov 14, 2009 at 15:00 UTC 
    package Foo;

## declare inside-out hashes here:

my %attr_a;
my %attr_b;

## declare private methods here

my $private_1 = sub {
  my $self = shift;
  # can use $attr_a{$self} here...
  ...
};

my $private_2 = sub {
  my $self = shift;
  ... 
};

## public methods here

sub new { ... }

sub public_1 {
  my $self = shift;
  # can access attributes here
  # can call private methods too, with slightly odd syntax:
  my $result = $self->$private_1(@args);
  ...
}

1;

    [download]

    -- Randal L. Schwartz, Perl hacker

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

[reply]
[d/l]
      Thanks!
[reply]
Re: perl OO private methods
by Tanktalus (Canon) on Nov 14, 2009 at 15:01 UTC

    Yes, you can. But it's not entirely straightforward, and does it really matter? Perl has a convention that thou shalt not call methods outside your package that start with an underscore. But, if you know what you're doing, you still can. After all, the module author may be wrong and that function might really be needed. I know I've been on both ends of that before: both needing a function that was deemed private (started with a leading underscore), and marking a function private with the underscore that was later needed elsewhere. So it's nice that perl doesn't shackle the developer.

    If you really need to, you can do something like this in your SOD::MyOOInterface package (or wherever you want the private method): 

    my $_some_method = sub {
  # method here.
};

sub externalised_method {
  #...
  $_some_method->(@some_args);
  # or
  $self->$_some_method(@some_args);
  #...
}

    [download]
    Because it's an anonymous function, no one who can't see the variable that holds its reference will be able to call it. But because it's a lexical to the current package, only methods/functions in the current package can see the variable, thus making it effectively hidden to anyone else: private.

    Now, if you want protected equivalent, I don't know how to do that ... but, again, don't: that's not the perlish way.

[reply]
[d/l]
      thanks very much!
[reply]
      You could simulate a protected method by having the method check caller() and die if the caller's not in the same package. You'd also need to use merlyn's trick to hide the method from anyone else; if it were allowed to live in the symbol table then it would be easy to swizzle it to a replacement unprotected version.

      Generally speaking, Perl programmers are willing to abide by the APIs: if you call a private method, then you're assuming the maintenance burden for it. So: don't bother. Document as internal use only and subject to change.

[reply]

Back to Seekers of Perl Wisdom