Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Learning to write modules by example.

Reply
Thread Tools

Learning to write modules by example.

 
 
Justin C
Guest
Posts: n/a
 
      02-01-2013

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.
 
Reply With Quote
 
 
 
 
Rainer Weikusat
Guest
Posts: n/a
 
      02-01-2013
Ben Morrow <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
Justin C
Guest
Posts: n/a
 
      02-05-2013
On 2013-02-01, Ben Morrow <(E-Mail Removed)> wrote:
>
> Quoth Justin C <(E-Mail Removed)>:
>>
>> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[I'm learning C]: Learning to use ucontext Andrey Popp C Programming 5 01-31-2012 01:05 AM
Learning which modules were loaded James Stroud Python 1 06-06-2008 09:40 PM
Learning C and Learning Make/Configure/Building/Linking Hal Vaughan C Programming 7 03-21-2006 05:07 PM
e-learning, (collaborative learning environment) collinm Java 1 09-08-2005 09:52 PM



Advertisments