A fair degree of privacy is gotten by constructions like you discuss. You have very well described the use of closures for private data and methods.

What I really applaud is your conclusion. Perl is not an enforced OO language. Like C++, it is a mixed language with support for OO but no requirement. Unlike C++, perl's OO constructs get by with conventions about what methods may be called reliably. We name private methods with a leading underscore, and we don't care what happens to people who call them from outside.

This voluntary cooperative model of OO gives the screaming horrors to Smalltalkers and other purists, but it leaves a lot of space for us to work in. Mixed model languages are so much more comfortable to work in. The design of a program does not have to be pounded into any One True Shape.

I often hear perl programmers say stuff like " We name private methods with a leading underscore, and we don't care what happens to people who call them from outside." and other stuff relating to not enforcing privateness in objects. I used to think this was a good thing, a benefit of perl, after all, if he really wants to do that, shouldn't he be able?

Thats completely missing the point though. The point of private methods and data *isn't* to enforce your "one true shape" on any programmer that tries to use it, the point is so that you can inherit from it without worrying about what the hell your parent class did.

Perl's object instance data is the main part that suffers from lack of privateness, anything you do in the child class with specifically affect the parent class, so if you want to use a specific key in your child hash, you'd better hope the parent doesn't, at any time, want to use this key! Sure theres some work arounds, but this is perl, we aren't supposed to have to take the long, unwieldy, verbose way to do stuff. It's supposed to be short, succint and to do what we mean.

This voluntary cooperative model of OO gives the screaming horrors to Smalltalkers and other purists, but it leaves a lot of space for us to work in.

Most versions of Smalltalk do not actually have any notions of public/private/protected in the way Java/C++ does. Instead Smalltalk's notion of private methods is very similar to perl's, "If you weren't invited, don't come in". Smalltalk has things called method categories, which in the language are really are nothing more than syntactic sugar, but when you combine it with the Smalltalk environment, in particular the Smalltalk code browser, you have another layer of organization between the class-level and method-level. Typically Smalltalk programmers will put all their private methods into the "Private" category. Some Smalltalk implementations will complain (the equivalent of warn) when you call a method that is prefixed with an _ from outside of your class, but none (at least that I know of) will actually enforce this and not let you compile your code. Here is a link that goes into more detail if you are intetested.

-stvn

This voluntary cooperative model of OO gives the screaming horrors to Smalltalkers and other purists ...

I assume that was meant in jest. This Smalltalker is not especially bothered by voluntary cooperation. I'd rather enable than restrict.

You might find Private method variations of interest.

I think you may be missing the point of private methods (I know I did at first).

The programmer's intent is to keep other objects/scripts from using these methods.

I know a lot of programmers insist that you need private methods, but thats like saying 'I expect programmers using my class to be idiots'. And, well, if they're idiot, then too bad. :P

I (mostly) agree with this. The way I view it is that the "public" methods provided by a class are in essence the contract that the object provides to the outside world. I see contracts as two-way, I (as the user of the class) need to fufill my end of the contract (don't touch the private methods) in order to use your class.

However, there is a huge problem today with software reliability, and building really good, really reliable and really flexible software components is still a black art, and one that very few people/companies can really get right (and more importantly sustain, it does me no good if its not updated). Whole methodologies have sprung up that are partially an attempt to fix/address these problems (Design by Contract, Test Driven Development, etc etc etc). IMO, if you are releasing your code, anything you can do to secure it, and assure that it performs as advertised is a good thing. And keep in mind that this means breaking and die-ing in all the right places as well, that is an oft under-developed part of many modules.

Personally I just put an _ in front of my private methods and a comment tell people "This is private, use at your own risk". However, I do find the need sometimes for protected methods (ones that can only be accessed by subclasses), and for that I use this minimal Design-By-Contract inspired snippet:

sub _my_protected_method { 
    ((caller)[0]->isa(__PACKAGE__)) 
        || die "This method can only be called by a subclass";
    # ... do something 
}
[download]

To be honest, I usually don't feel that method encapsulation is a big issue. However, encapsulation of instance data is another issue (which you addressed this in your previous post). For that I use the module I created (Devel::StrictObjectHash), which works somewhat like use strict in that it really just serves to keep you from shooting your own foot off.

Personally I just put an _ in front of my private methods and a comment tell people "This is private, use at your own risk".

Tell me, do you also document it? If you do, you belong to an extremely small minority.

ihb

Tell me, do you also document it?

Do you mean document, as in comments? Almost always yes, unless the code itself is so glaringly obvious that it needs no documentation.

If you mean document, as in POD? Then the answer is sometimes. Documenting private and protected methods in POD is only really useful for those who want to subclass your module, and I try to make sure to point that out when I do so as not to confuse.

-stvn

Why would someone want to document private methods?

Documentation is a promise that something won't change. Part of the point of keeping private methods private is that they might change in future versions. Those goals are in conflict with each other.

I also agree with the conclusion though, and the books nice anology: Perl doesn't keep you out of its space with a shotgun, it assumes you will respect its boundaries anyway. (probably misquoted ,) Module programmers should do the same..

C.

"Perl would rather you stay out of its living room because it asked you, not because it has a shotgun."

package Foo;

sub new { bless {}, shift }

sub _method1 { print "Foo::_method\n"; }
sub method2 { my $self = shift; $self->_method1 }

package Foo::Bar;

@ISA = qw( Foo );

sub _method1 { print "Foo::Bar::_method\n"; }

package main;

my $foobar = Foo::Bar->new;
$foobar->method2;
[download]

The code is being called from within the Foo class, but method lookup finds the _method1() within the Foo::Bar class. *shrugs* I'm not sure where this leads, but that's the reason why. :-)

Perhaps just

sub method2 { my $self = shift; _method1( $self ); }
[download]

or am I missing something really obvious in this example ?

Or for better general safety, mark the privates to make their names unique.

package Foo;

sub _F_method1 { print "Foo::_method\n"; }
sub method2 { my $self = shift; $self->_F_method1; }


package Foo::Bar;

@ISA = qw( Foo );

sub _F_B_method1 { print "Foo::Bar::_method\n"; }

package main;

my $foobar = Foo::Bar->new;
$foobar->method2;
[download]

update: s/exclusive/unique/

sub method2 { my $self = shift; _method1( $self ); }
[download]

or am I missing something really obvious in this example ?

Yes. If you don't override _method1 in the subclass, nothing will be called.

----
send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.

If you're inheriting from someone else, you're mucking around with their internals.

If you're uncomfortable doing so, then you shouldn't be inheriting.

tilly, you have a tendency to toss out statements like that without explaining what you mean (that's not intended as criticism.) Are you stating that all OO languages are like this? Clearly you are referring to more than just a blessed referent. With much tighter encapsulation available with Java or C++, do you mean even these languages have the programmer automatically mucking with internals upon subclassing or is this a peculiarity of Perl (or dynamically-typed languages)?

Cheers,
Ovid

New address of my CGI Course.

I too am bother with this and I shrug when I see     $self->_private(@args) because hardly ever has the author documented &_private so I have to be extra careful when extending it and writing my own help routines.

And I really cry when I see     $self->_init(@_); in the parent class after trying to debug a totally innocent subclass, which happened to have a little help routine called &_init.

IMHO, it's just not particularly clever to call a "private" method as a method since you don't need the method dispatch to find the subroutine, plus you risk being accidently overridden.

Private methods should be invoked as (help) functions, because that's what they are.     _private($self => @args) is my preferred style.

ihb

You might find this paper (its a PDF) interesting, it is by the same group that brought us Traits. It talks about adding a more flexible encapsulation policy to Smalltalk (it's concepts though are applicable to most dynamic OO languages (perl, python, etc)).

The author discusses the idea that many times you need more than one encapsulation policy. The simplest example being; one for public use, and one for use by subclasses (which would be roughly equivalent to public and protected), but they take it to the next level really. Interesting read.