37

I am working on a little Perl module and for some reason I had the test driver script that was using my new module call one of the functions that I thought would be private, and it was successful. I was surprised, so I started searching google and I couldn't really find any documentation on how to make private functions in Perl modules...

I saw one place that said to put a semicolon after the closing brace of your "private" function, like this:

sub my_private_function {
...
}; 

I tried that, but my driver script could still access the function I wanted to be private.

I'll make up something that will be a shorter example, but here's what I'm after:

Module TestPrivate.pm:

package TestPrivate;

require 5.004;

use strict;
use warnings;
use Carp;
use vars qw($VERSION @ISA @EXPORT @EXPORT_OK);

require Exporter;

@ISA = qw(Exporter AutoLoader);

our @EXPORT_OK = qw( public_function );
our @EXPORT    = qw( );

$VERSION = '0.01';

sub new {
    my ( $class, %args ) = @_;
    my $self = {};
    bless( $self, $class );
    $self->private_function("THIS SHOULD BE PRIVATE");
    $self->{public_variable} = "This is public";
    return $self;
}

sub public_function {
    my $self     = shift;
    my $new_text = shift;
    $self->{public_variable} = $new_text;
    print "Public Variable: $self->{public_variable}\n";
    print "Internal Variable: $self->{internal_variable}\n";
}

sub private_function {
    my $self     = shift;
    my $new_text = shift;
    $self->{internal_variable} = $new_text;
}

Driver: TestPrivateDriver.pl

#!/usr/bin/perl
use strict;
use TestPrivate 'public_function';
my $foo = new TestPrivate();
$foo->public_function("Changed public variable");
$foo->private_function("I changed your private variable");
$foo->public_function("Changed public variable again");
$foo->{internal_variable} = "Yep, I changed your private variable again!";
$foo->public_function("Changed public variable the last time");

Driver output:

Public Variable: Changed public variable
Internal Variable: THIS SHOULD BE PRIVATE
Public Variable: Changed public variable again
Internal Variable: I changed your private variable
Public Variable: Changed public variable the last time
Internal Variable: Yep, I changed your private variable again!

So I added a semicolon after the last closing brace in the module, but the output is still the same. The only thing I really found was to add this line as the first line to my private_function:

caller eq __PACKAGE__ or die;

But that seems pretty hacky. I don't have a lot of experience writing Perl modules, so maybe I am setting my module up incorrectly? Is it possible to have private functions and variables in perl modules?

Thanks for helping me learn!

brian d foy
  • 129,424
  • 31
  • 207
  • 592
BrianH
  • 7,932
  • 10
  • 50
  • 71
  • If you're writing an OO class, you can get rid of the EXPORT stuff. That has nothing to do with methods or visibility. – brian d foy Jan 16 '09 at 21:16
  • I only tried exporting functions because I thought it would make the other ones not export, or private. Now I know that wouldn't help. – BrianH Jan 16 '09 at 23:55
  • I think you should reconsider your "correct" answer. You *can* accomplish what you want, but you have to use something like what Brian Phillips or Brian D Foy suggest, an inside-out class structure. There's a book called "Perl Best Practices" that has a chapter or two devoted to the concept. – Joe Casadonte Jan 17 '09 at 14:33

9 Answers9

38

From perldoc perltoot (about a quarter way through the document):

Perl doesn't impose restrictions on who gets to use which methods. The public-versus-private distinction is by convention, not syntax. (Well, unless you use the Alias module described below in "Data Members as Variables".) Occasionally you'll see method names beginning or ending with an underscore or two. This marking is a convention indicating that the methods are private to that class alone and sometimes to its closest acquaintances, its immediate subclasses. But this distinction is not enforced by Perl itself. It's up to the programmer to behave.

Therefore, I recommend you put an underscore or two at the beginning of your "private" methods to help dissuade usage.

jedihawk
  • 814
  • 1
  • 12
  • 12
  • Yeah - I noticed the underscore prefix too - I tried that thinking it was some magical perl way of making a function private. I guess that's just a "warning", but not enforceable. – BrianH Jan 16 '09 at 19:14
  • 8
    "Undersore"? Lovely image. – AmbroseChapel Jan 16 '09 at 22:45
  • 3
    Beginning with Perl 5.18, you can declare a private subroutine with 'my' or 'state'. https://perldoc.perl.org/perlsub.html#Lexical-Subroutines – Беров Dec 14 '17 at 00:09
23

There is only "The Kludge" of storing a code reference in a lexical variable, which no one outside that scope can see:

my $priv_func1 = sub { my $self = shift; say 'func1'; };

sub public_sub { 
    my $self = shift;

    $priv_func1->( $self );
}

And I can't think of a way to make rigorously "protected" fields.

That's it as far as I know ( besides source filters...shhhh. I didn't mention them.... )


EDIT: Actually, it turns out I can think of a very messy way of doing protected. But it would probably involve passing all calls through the AUTOLOAD sub. (!!)

Axeman
  • 29,660
  • 2
  • 47
  • 102
  • 1
    ["Inside-Out objects"](http://perldoc.perl.org/perlobj.html#Inside-Out-objects) can be used to make `private` fields, in C++(ish) terminology. As in, the data is actually stored in a separate hash. – Arne Vogel Jun 04 '18 at 10:56
15

This works:

my $priv_func1 = sub {
    my $self = shift; say 'func1';
};

sub public_sub { 
    my $self = shift;

    $self->$priv_func1(@_);
}
Leon Timmermans
  • 30,029
  • 2
  • 61
  • 110
  • It's less efficient though, as calling $priv_func requires a variable dereference at runtime. – Ether Aug 01 '09 at 18:24
  • 15
    Ether: You're completely wrong, it's more efficient in fact, because it doesn't require method lookup. – Leon Timmermans Aug 11 '09 at 11:16
  • The only thing with this one is (and this bit me) - you have to make sure the private method is declared before you try to use it. You don't have to give the full definition, you just have to declare the variable. You can define it later if you want (kinda like in C). my $priv_func1; sub public_sub { my $self = shift; $self->$priv_func1(@_); } $priv_func1 = sub { my $self = shift; say 'func1'; } – livefree75 Jan 16 '15 at 18:40
9

Just check caller:

package My;

sub new {
  return bless { }, shift;
}

sub private_func {
  my ($s, %args) = @_;
  die "Error: Private method called"
    unless (caller)[0]->isa( ref($s) );

  warn "OK: Private method called by " . (caller)[0];
}

sub public_func {
  my ($s, %args) = @_;

  $s->private_func();
}

package main;

my $obj = My->new();

# This will succeed:
$obj->public_func( );

# This will fail:
$obj->private_func( );
JDrago
  • 2,079
  • 14
  • 15
  • 1
    I would think this would be possible to do in a more modular fashion with a method attribute. – Ether Aug 01 '09 at 18:25
6

What are you trying to do? Maybe there is a better Perl way of doing whatever you are trying to accomplish.

For instance, if you don't want people mucking around in your objects because you want to enforce encapsulation, you can use something like Class::InsideOut. That module has a Class::InsideOut::About documentation module that explains the concept. There is also Object::InsideOut, which Brian Phillips already mentioned.

brian d foy
  • 129,424
  • 31
  • 207
  • 592
  • Your best bet is indeed to use Class::InsideOut or Moose http://www.catalyzed.org/2009/06/a-gentle-introduction-to-moose.html – Drew Stephens Sep 18 '09 at 00:15
  • 1
    Lucky thing I don't gamble then. The better best bet is to analyze the situation and evaluate the options according to what you find. :) – brian d foy Sep 18 '09 at 14:47
3

This style of OO starts to feel a little "un-perlish" after a while when you realize you can't just use Data::Dumper to dump the object directly or peek inside the object to look at its data. However, if you want to give it a shot, I'd recommend using Object::InsideOut. It supports private data and methods for your objects along with a number of other handy features (accessor generation, default constructor, etc).

brian d foy
  • 129,424
  • 31
  • 207
  • 592
Brian Phillips
  • 12,693
  • 3
  • 29
  • 26
3

We can write some thing below in the perl private function to check whehter the call from the same obj as caller[0] gives package.

sub foo {
  my ($s, %args) = @_;
  die "Error: Private method called"
      unless (caller)[0]->isa( ref($s) );
}
Grzegorz Rożniecki
  • 27,415
  • 11
  • 90
  • 112
2

If you use a system like Moose, you can get a public/private distinction as seen here.

Oesor
  • 6,632
  • 2
  • 29
  • 56
Chris Simmons
  • 1,843
  • 1
  • 12
  • 18
  • That's a pretty gross recipe -- try this instead: http://search.cpan.org/~franckc/MooseX-MethodPrivate-0.1.2/lib/MooseX/MethodPrivate.pm – Ether Oct 15 '09 at 19:29
  • @ether stale link @chris you too, but I submitted and edit for yours. you guys should leave the versions out and use dist/ instead of ~author/ – xenoterracide Feb 16 '11 at 13:08
  • Amended link: http://search.cpan.org/perldoc?MooseX::MethodPrivate (@xenoterracide: you do realize that comment is over a year old? ;) ) – Ether Feb 18 '11 at 20:08
  • 1
    @ether no didn't think about it... moderator's can still modify, idk about 10k people or not. I'm just trying to be a good citizen and keep SE accurate – xenoterracide Feb 19 '11 at 00:28
0

In File for your package: Define private methods as CODE-Ref, i.e.:

my $private_methode = sub{};
LittleBobbyTables - Au Revoir
  • 32,008
  • 25
  • 109
  • 114
Rolf
  • 19
  • 3