Learning to write modules by example.
 

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.

Re: Learning to write modules by example.
 

Ben Morrow <ben@morrow.me.uk> 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.

Re: Learning to write modules by example.
 

On 2013-02-01, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth Justin C <justin.1211@purestblue.com>:
>>
>> 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.