Learning to write modules by example.

Discussion in 'Perl Misc' started by Justin C, Feb 1, 2013.

  1. Justin C

    Justin C Guest

    I've written a few in-house modules for use within the business here
    and they're ugly. I recently had reason to write a few new ones to
    replace some procedural stuff that needed to be updated anyway, so I
    thought I'd do it properly and write some sensible OO modules - a
    module makes more sense for them anyway.

    I started off OK, but it soon got ugly again (though much less so).
    I've been reading perlmodstyle, and I've also read José's Guide for
    creating Perl modules (though it is a little old). What I think
    would be useful would be to read the source of a great existing
    module, one that's been written with 'best practice' in mind. Now I
    can look at any of the hundreds of modules I have installed but I
    don't know which ones are considered to be well (or very well)
    written, so, can people recommend good examples of 'the best way to
    do it'? I don't want to pick one and find it's the worst one from
    which to learn by example.

    As alway, thank you for your suggestions.


    Justin.

    --
    Justin C, by the sea.
    Justin C, Feb 1, 2013
    #1
    1. Advertising

  2. Ben Morrow <> writes:

    [...]

    > As far as non-Moose OO goes: the TAP::* modules are fairly newly written
    > by people who know what they're doing; the CPANPLUS code is also pretty
    > clean, as are the various modules making up LWP. However, current best
    > practice is to use Moose for OO code, at least for large systems;


    Everybody who ever implemented "Jonathans very own version of an OO
    programming system" was presumably convinced that HIS idea of how this
    should work was Very Much Superior[tm] to the ideas of all other
    people. AFAIK, Moose is more-or-less the Perl6 OO system reimplemented
    atop of the perl5 interpreter in Perl. I can't comment on the merits
    of Perl6 OO because I have never used it. But the idea of implementing
    support for fundamental programming paradigms in form of 'interpreted'
    extension libraries is a very bad one. People who want to use Perl6
    OO should use Perl6. And people who want to use Perl5 for some reason
    would be well-advised to stick to the features provided by the perl
    implementation itself if they want to write reasonably efficient
    'production quality' code (*except* insofar they happen to be
    conslutants whose involvement with any project ends long before
    'making it work in the real world' becomes an issue -- the 'download
    whatever you can' approach is perfect of 'optimizing' the income/ work
    ratio in such a setting: Get paid for selling other peoples'
    code. Move on before the problems start to hit you).

    The perl5 OO system is perfectly usable. Like all systems, it has its
    advantages and its drawbacks.
    Rainer Weikusat, Feb 1, 2013
    #2
    1. Advertising

  3. Justin C

    Justin C Guest

    On 2013-02-01, Ben Morrow <> wrote:
    >
    > Quoth Justin C <>:
    >>
    >> I've written a few in-house modules for use within the business here
    >> and they're ugly. I recently had reason to write a few new ones to
    >> replace some procedural stuff that needed to be updated anyway, so I
    >> thought I'd do it properly and write some sensible OO modules - a
    >> module makes more sense for them anyway.
    >>
    >> I started off OK, but it soon got ugly again (though much less so).
    >> I've been reading perlmodstyle, and I've also read José's Guide for
    >> creating Perl modules (though it is a little old). What I think
    >> would be useful would be to read the source of a great existing
    >> module, one that's been written with 'best practice' in mind. Now I
    >> can look at any of the hundreds of modules I have installed but I
    >> don't know which ones are considered to be well (or very well)
    >> written, so, can people recommend good examples of 'the best way to
    >> do it'? I don't want to pick one and find it's the worst one from
    >> which to learn by example.

    >
    > As far as non-Moose OO goes: the TAP::* modules are fairly newly written
    > by people who know what they're doing; the CPANPLUS code is also pretty
    > clean, as are the various modules making up LWP. However, current best
    > practice is to use Moose for OO code, at least for large systems;
    > Catalyst would be a good example of a system which was cleaned up a lot
    > by switching to Moose.
    >
    > All OO code that will run on 5.10 or above should at least
    >
    > use mro "c3";
    >
    > at the top of the class heirarchy and use the next::method facility
    > (documented in perldoc mro) rather than SUPER::.


    Thank you, Ben. I'll do some reading.

    Justin.

    --
    Justin C, by the sea.
    Justin C, Feb 5, 2013
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Porky Pig Jr
    Replies:
    3
    Views:
    369
    Dave Cole
    Aug 24, 2004
  2. Robert Brewer
    Replies:
    4
    Views:
    380
    Porky Pig Jr
    Aug 24, 2004
  3. Hal Vaughan
    Replies:
    7
    Views:
    463
  4. Replies:
    1
    Views:
    343
  5. Andrey Popp

    [I'm learning C]: Learning to use ucontext

    Andrey Popp, Jan 29, 2012, in forum: C Programming
    Replies:
    5
    Views:
    688
    Keith Thompson
    Jan 31, 2012
Loading...

Share This Page