Am I wrong to want to do this? I like making everyone who's using my module happy. I like the flexibility.

My point is that if a module or library really benefits from being constructed using the OO style; a procedural interface to it doesn't make sense.

Conversely, if a module/library lends itself better to a procedural interface, adding an pseud-OO interface also, doesn't add flexibility, it adds unnecessary complexity.

For example. You'll find a bunch of statistics modules on CPAN that have OO interfaces. You create an instance; add your data to that instance either item by item or on mass; and then call various methods on it to retrieve the stats.

Which is fine if your script consists of: reading a file of data; and then outputting the required stats to the screen or a file. Only.

But most of the time in my scripts; the data I want stats on is wrapped up in some larger data structure that gets used for drawing graphs or processing to images or any number of other processes. The stats is just a small step in the overall picture.

Having to copy the data from where it lives into a object in order be able to get the average and stddev, means duplicating the memory and copying stuff from place to place; when all I want or need is:

...
    my( avg, $stddev ) = avgNstddev( $bigStruct->{something}{something
+else} ); ## hash expression yields an array ref.
...
[download]

In this case, an OO interface would require:

...
    my $stats = Stats:Mod->new;
    $stats->add( $_ ) for @{ $bigStruct->{$something}{$somethingelse} 
+};
    my $avg = $stats->avg;
    my $stddev = $stats->stddev;
    $stats->empty;
...
[download]

Not only more complex code; but in the process I trebled the memory requirement: the original source of the data; the list created by the for; and the copy held internally by the object. If the array is large, that's a problem.

If the ...s in the two snippets above are:

for my $something ( keys %bigstruct ) {
    for my $somethingelse ( keys %{ $bigstruct->{ $something } } ) {
         ...
    }
}
[download]

It starts to be a big and expensive problem.

Now, for some types of stats, an OO interface makes sense because some calculations can benefit greatly from caching results from earlier calculations. Simple example, If you need both the average and stddev, having separate functions for each means you'll probably end up calculating the average twice. Whereas an object interface can cache the average internally and reuse it for the stddev; or if stddev is called first, calculate and cache the average whilst calculating the stddev and when (if) the average method is called, avoid having to recalculate it by returning it from cache. And both cached values can be reused when calculating the return for other methods.

But rather than then forcing me to add my data to an object to get the simple values; make the average() a separately callable sub (or a class method) that takes an array ref, usable procedurally. Then have the object interface use that internally to calculate averages, Ditto for stddev(). Have it be another sub/class method with parameters of the array ref and their average.

That way, for the simple cases, I can use the procedural interface, and only use the OO interface for the more complex calculations.

Of course, the best interface might be to have the OO stats module take an array ref as the argument to its constructor:

my $stats = Stats::Module->new( $bigstruct->{ $something }{ $something
+else } );
my( $avg = ( $stats->average, $stats->stddev );
$stats->done;
[download]

Still a little more code than the simple procedural interface; but with the advantage that it can handle the more complex operations without needing to replicate the data internally. Of course, it comes at the cost that if you modify the data between calls to methods for the various stats, it could try calculating the stddev for the modified data by reusing the cached average calculated against the original data.