Actually you can share state in the package variables, but only one set of them.

This pattern is similar to a singleton object in OOP.

(The modular interface of Data::Dumper is a good example for that, with the global config vars, like $Data::Dumper::Indent )

But you are right, a very good reason to use methods instead of functions is if they all start to look like this

package Do_Something

my %repeated = init();

foo( X, %repeated);

bar( Y, %repeated);

...
[download]

then it's obviously better to write

my $obj = Do_Something->new(%init);

$obj->foo(X);

$obj->bar(Y);
[download]

especially if there is a chance that you might need to have different initializations in the same code

my $obj2 = Do_Something->new(%other_init);
[download]

( see Data::Dumper again with it's alternative OOP interface, where the configs are encapsulated in the objects like $OBJ->Indent([NEWVAL]) or $OBJ2->Indent([NEWVAL]) )

On a side note: I prefer to think about objects like actors which do things, not containers which have attributes.

So reducing them to shared data is not the whole picture.

Last but not least: PBP lists some criteria when to use what...

For completeness: You can also share state between functions with the help of closures.
- Ron

Actually I'd rather prefer Dumper instances implemented as closures.

The setup methods here are just constructors in disguise, no need to call them more than once.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

So if I only want methods that take a value and return another value, it will be procedural...

That's a beautifully elegant exppanation choroba - thnk you

I don't think this is necessarily true. The whole "data encapsulation" thing is a little fuzzy in practice with Perl. I think most people can agree to this. Having that deref syntax is nice, particularly if you tend to use a lot of hash refs.