rduke15 has asked for the wisdom of the Perl Monks concerning the following question:

I have several scripts which it would seem wise to turn into modules. Unfortunately, even though I have been using Perl for a long time, OO concepts still tend to feel unfamiliar to me.

I could certainly just follow perootut and perlobj, but I understand that learning Moo or something similar would make it much easier in the end, by delegating a lot of boilerplate code to such a constructor module. If only I could understand it's basics, and know where to look for simple examples...

Basically, what I do is read a file into one or more hashes, manipulate the data and write the file back.

My current interest is mainly in files like edit lists (like Avid ALE files) and subtitles of various formats (including binary formats, for which there is nothing in CPAN currently). Doing the whole thing in a simple Perl script is pretty straightforward, but I'm sick of copy/pasting chunks of code from previous scripts, and would like to learn doing it the "right way" with various modules for the various formats.

What do the wise monks think? Where can I find examples to get me started? Or am I overengineering this, and would a plain module without /Mo.*/ or /Class::.*/ be much simpler?

  • Comment on tutorials / examples to start using Moo (or Class::Tiny, or...?)

Replies are listed 'Best First'.
Re: tutorials / examples to start using Moo (or Class::Tiny, or...?)
by CountZero (Bishop) on Jul 21, 2015 at 17:52 UTC
    I have several scripts which it would seem wise to turn into modules. Unfortunately, even though I have been using Perl for a long time, OO concepts still tend to feel unfamiliar to me.
    Modules and OO concepts are two entirely different things. It is quite possible and easy to gather your common code into a module (as some kind of "commonly used subroutines" repository) and use that without any hint of OO.

    So the answer to your last question is probably "yes".

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

    My blog: Imperial Deltronics
      I definitely agree with CountZero. You can write modules without using Moose, Moo or some other OO framework. From your description of what you are trying to do, I do not see very much use of a OO framework. A simple functional module might just fit the bill. Having said that, I have nothing against OO framework, I am just not sure that this is what you need.
Re: tutorials / examples to start using Moo (or Class::Tiny, or...?)
by neilwatson (Priest) on Jul 21, 2015 at 17:41 UTC
Re: tutorials / examples to start using Moo (or Class::Tiny, or...?)
by 1nickt (Canon) on Jul 22, 2015 at 03:31 UTC

    I agree, make functional modules. No need to make OO code by the sound of it.

    Also I suggest you look into Exporter::Tiny so you can import your subs into the program in which you are using the modules.

    The way forward always starts with a minimal test.
Re: tutorials / examples to start using Moo (or Class::Tiny, or...?)
by karlgoethebier (Abbot) on Jul 21, 2015 at 19:52 UTC
    "...several scripts which it would seem wise to turn into modules... read a file into one or more hashes, manipulate the data and write the file back...am I overengineering this...?"

    One of my first posts on PM was about something similar - less or more: The Way I Moo

    To be honest: i gave up this concept (in this case) and switched back to plain old modules.

    And worse: From time to time i put the stuff (my subs) in one file (the script), even if i repeat myself ;-)

    Best regards, Karl

    P.S.: About the basic theme (overengineering...): IMHO yes.

    «The Crux of the Biscuit is the Apostrophe»

Re: tutorials / examples to start using Moo (or Class::Tiny, or...?)
by gnosti (Chaplain) on Jul 23, 2015 at 01:50 UTC
    Others have written that OO and modular programming are somewhat orthogonal. So, if modules will enable you to refactor and reuse your code as subroutines, that is the simplest path forward. OTOH, if you are using complex data structures, or families of data structures, OO does help by keeping the code for initializing these structures and methods for operating on them in one place.

    If you haven't experienced how OO can help you organize your code, it is definitely worth learning, IMO. In that case, I find vanilla perl OO to be a good starting point, since you can see how it works more easily than with an OO framework. I started that way, then began using Object::Tiny to create accessors. In a new project, I would probably try Moo and friends.