I was asked to expand on my comments about ties as being good ways of hiding an object's implementation. I will use Tie::Cycle.

here is a normal usage of this module:

use Tie::Cycle;

tie my $cycle, 'Tie::Cycle', [ qw( FFFFFF 000000 FFFF00 ) ];

print $cycle; # FFFFFF
print $cycle; # 000000
print $cycle; # FFFF00
print $cycle; # FFFFFF  back to the beginning
[download]

From the standpoint of a person who is used to getting at object internals, he has no hope here. In fact, higher management could install the Tie::Cycle module, and the programmers would be free to use the module, making use of normal Perl syntax but with Tie::Cycle semantics.

But in no case could they use their tied scalar to access their "object" in this case, $cycle.

It's funny that I wrote this post, because I used to hate Perl ties. My way of describing them was:

They take a perfectly obvious piece of Perl code and make it so you have no idea what it might do anymore.

But after reading Ovid's post, I guess I have to say

They take a Perl module whose privates might have been violated using OOP availability and allow Perl to do the FETCHing and STOREing for the programmer, with a large variety of available semantics.