http://www.perlmonks.org?node_id=994971


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

I know there are some great modules on CPAN that implement this sort of dual interface.

Which do you have in mind? The only one I can think of is CGI, and it's either the worst example of a dual interface or the best, in that it's slow, complicated, potentially very buggy, and difficult to maintain.

For me the important question is whether an operation needs to encapsulate some kind of state. If so, I use an object interface. If not, I use a procedural interface.

I want to avoid using these until I have a solid grasp of how to implement OO in Perl by hand.

That sounds backwards to me. I've written my own regular expression engine, but I wouldn't suggest someone take a class on automata before performing simple matches.

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

Replies are listed 'Best First'.
Re^2: module w/ object-oriented and functional interfaces: best practices?
by temporal (Pilgrim) on Sep 21, 2012 at 19:33 UTC

    Okay, you've got me there chromatic. I am definitely not any sort of an authority on what constitutes a "great" CPAN module ;)

    But I do see this sort of thing a lot... most recently when I was fiddling with upgrading my config file loading with Config::General:

    # the OOP way use Config::General; $conf = new Config::General("rcfile"); my %config = $conf->getall; # the procedural way use Config::General qw(ParseConfig SaveConfig SaveConfigString); my %config = ParseConfig("rcfile");

    I'd like my modules to be able to do this in the most intelligent way possible! Which, as it turns out, requires intelligently considering how your module is being used and your own requirements. Curses, I hate intelligently considering things.

    Anyway, as for going about it 'backwards', you're probably right. I take a learn-first, apply-later approach to things. Admittedly not that efficient (I could just use Moose and forget about all the small stuff involved in Perl OO). But I'd rather investigate what's really going on with the small pieces first and then jump up to using the feature-rich tools other people have built from them.

    I'm here to enjoy myself tinkering with the ins and outs, the pieces and possibilities first and get work done (close) second. Don't tell my boss =P

    But I think I come out ahead in the long run in terms of getting things done. We're getting to that old 'bottom-up' vs 'top-down' learning style argument, haha.

    Strange things are afoot at the Circle-K.