Learning to write modules by example.

J

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 alway, thank you for your suggestions.


Justin.
 
R

Rainer Weikusat

[...]
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.
 
J

Justin C

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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top