[Melbourne-pm] Namespace Guidelines?
Kat Grant
crashkat at gmail.com
Wed Jan 2 20:03:30 PST 2008
Thanks Paul
This pretty much covers what I was looking for. Still wish I could
find that (perhaps imaginary) article that I think i read, but this
will do.
Cheers
K
On 01/01/2008, at 10:32 PM, Paul Fenwick wrote:
> G'day Kat and Melb.pm,
>
> Kat Grant wrote:
>
>> Does anyone know of any nice articles outlining guidelines for OO
>> perl namespaces?
>
> You can find some advice under "Select a name for the module" in
> perlmodlib.
> There's also the perl modules list, which is filled with incredibly
> pedantic CPAN admins. While it's primarily useful in getting
> namespaces
> sorted for upload to CPAN, if anyone does have a good set of
> guidelines
> written down, they will. You can try dropping a mail to them at
> modules at perl.org, or you can do what I do and find Adam Kennedy as
> my local
> CPAN admin on IRC (he's usually found as 'alias' on #win32 on
> irc.perl.org).
>
> When uploading to CPAN, my general rules would be:
>
> * Go from most general to most specific
> * Follow existing conventions when possible
> * Talk to others for a sanity check
>
> The "Local::" namespace is reserved for modules that will never be
> distributed (and never appear on CPAN); however it appears there's
> also a
> guarantee[1] that there won't be any modules on CPAN which contain
> underscores. So a prefix in the style of My_Business:: can be used
> if you
> want to be absolutely sure there'll never be any sort of conflict.
>
> In my experience, the reserved namespaces look awful, so like many
> companies
> we've picked a short and obvious prefix for our internal modules
> (in our
> case, PTA:: ).
>
> As for OO guidelines, it's fairly natural for one to expect
> containership to
> mean inheritance. For example, Bird is a parent of Bird::Chicken is a
> parent of Bird::Chicken::Australorp. If you have nested packages that
> *don't* have inheritance (for internal modules) then I suggest you
> consider
> if there's a way to name about that. The same applies in the
> reverse; do
> you have inherited classes that end up in completely different
> packages? If
> you do, is there a good reason?
>
> Apologies for the not particularly in-depth response, however if
> you do find
> a good set of guidelines written down, I'd love to see them.
>
> All the best,
>
> Paul
>
> [1] According to perlmodlib
>
> --
> Paul Fenwick <pjf at perltraining.com.au> | http://perltraining.com.au/
> Director of Training | Ph: +61 3 9354 6001
> Perl Training Australia | Fax: +61 3 9354 2681
More information about the Melbourne-pm
mailing list