http://qs321.pair.com?node_id=561584

Dear brethren,

Perl's OO model famously (or notoriously) provides no support for private methods. One common way to achieve method privacy is to use "lexical methods":

use strict; use warnings; { package Foo; my $private = sub { my $self = shift; print "From $self: @_\n" }; sub public { my $self = shift; $self->$private( @_ ); } } ( bless [], 'Foo' )->public( 'Howdy!' ); __END__ From Foo=ARRAY(0x816cc20): Howdy!

This enforces privacy, all right! If anything it does it too well, since $private is not accessible even to external test programs. But then, something similar is true for private methods in other languages...

Anyway, here's an alternative that is less watertight but offers greater flexibility:

use strict; use warnings; { package Foo; sub restricted { die "Calling this method from external code is STRONGLY deprecated +\n" unless __PACKAGE__ eq caller; my $self = shift; print "From $self: @_\n" }; sub public { my $self = shift; $self->restricted( @_ ); } } my $foo = bless [], 'Foo'; $foo->public( 'Howdy!' ); $foo->restricted( 'Hey wassup!' ); __END__ From Foo=ARRAY(0x816cc20): Howdy! Calling this method from external code is STRONGLY deprecated

Granted, it is relatively easy to circumvent this little subterfuge with another one; just replace the external call to restricted with the first line below:

{ package Foo; $foo->restricted( 'Hey wassup!' ); } __END__ From Foo=ARRAY(0x816cc20): Howdy! From Foo=ARRAY(0x816cc20): Hey wassup!

At this point the subterfuge race can escalate with

use strict; { package Foo; sub terfuge { die "DON'T YOU BE CALLIN' THIS HERE METHOD, DANG IT!!!\n" unless __FILE__ . __PACKAGE__ eq join '', ( caller )[ 1, 0 ]; my $self = shift; print "From $self: @_\n" }; sub public { my $self = shift; $self->terfuge( @_ ); } } 1;
use strict; use warnings; use Foo; my $foo = bless [], 'Foo'; $foo->public( 'Howdy!' ); { package Foo; $foo->terfuge( 'Hey wassup!' ); } __END__ From Foo=ARRAY(0x816cc20): Howdy! DON'T YOU BE CALLIN' THIS HERE METHOD, DANG IT!!!

But I figure that if one feels the need to push this approach this far one may as well stay with the lexical private method described earlier. I prefer the second-to-last version, even though it can be easily circumvented, or rather, because it is easy to circumvent (which is useful during testing). I see it more as an extension of the docs than as a programmatic way to enforce privacy.

I don't recall this caller-based technique to enforce privacy as being used much, which makes me wonder if there are problems with it that I'm missing. Of course, many people, myself included, often find that naming conventions (e.g. the trusty leading underscore) are sufficient reminder of which methods are not meant to be used externally. The simple rule is something like "don't call anything that is not documented". This rule works well most of the time, but it is too restrictive in some cases. For example, it is very helpful to be able to invoke private methods when testing the public ones. But, especially in larger projects, I find that some private methods are more dangerous to call externally than others, and as the complexity of naming schemes increases, it becomes easier to lose track of what the various conventions mean. In such situations, an explicit check for potentially dangerous usage seems in order.

As always, I eagerly await your thoughts and comments.

the lowliest monk