Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Re: module w/ object-oriented and functional interfaces: best practices?

by temporal (Pilgrim)
on Sep 21, 2012 at 19:10 UTC ( #994981=note: print w/replies, xml ) Need Help??

in reply to module w/ object-oriented and functional interfaces: best practices?

Thanks for the replies, guys. Apologies about the lack of code provided BrowserUk, I definitely put too much emphasis on "convert my code" when what I really want is "how do you guys implement this in your own modules?".

Before going any further, I do understand the mechanics behind Perl OO - blessed hashref, etc. Thank you for reiterating them for me =)

My main reason for wanting to implement this is that I have to work with these modules, which are essentially libraries of functions. In some calling scripts all you want is some subroutine out of the module. I don't want to mess with all that OO stuff - quick, lightweight, simple and easy with Exporter.

On the other hand sometimes (increasingly so, for me) I'll want something with a little more permanence and I think that some of my modules are "growing" in this direction. I want to create several module objects which have individually loaded configs either from the constructor call or loading config files. Then working with the libraries within these modules is simpler than having to pass all my configuration options to an exported function or having to reload configurations for the module.

If your procedural functions were written (or could be easily modified) to take a hashref containing the data they operate on, then making the module "OO" could be as simple as adding a constructor sub that builds a hash from its inputs, blesses a reference to it and returns it.

I only pass a hashref in this manner for functions that require more than 3 arguments. So I'm partially in that boat. I think this is what I meant by converting my functions to create a temporary object each time a function is called.

Having both is often no more than paying lip service to peoples wont to have things work in one particular way.

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

Anyway, I am getting a very "look at your module usage and make up your mind one way or the other" vibe from you guys on this one. I'm a little surprised since so many CPAN modules support both pragmas.

I thought there might be a best practice style of going about this. Could be that the best practice style is decide which pragma is more important, write the module to support that, and then cobble the other pragma in as needed.

Strange things are afoot at the Circle-K.

  • Comment on Re: module w/ object-oriented and functional interfaces: best practices?
  • Download Code

Replies are listed 'Best First'.
Re^2: module w/ object-oriented and functional interfaces: best practices?
by BrowserUk (Pope) on Sep 21, 2012 at 20:22 UTC
    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. ...

    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; ...

    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 } } ) { ... } }

    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;

    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.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    RIP Neil Armstrong

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://994981]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (4)
As of 2017-10-20 07:17 GMT
Find Nodes?
    Voting Booth?
    My fridge is mostly full of:

    Results (259 votes). Check out past polls.