One package perl pm file
Recently one of our readers checked if Tie::ExtraHash was installed on his system running perl 5.18.0.
He used perl -MTie::ExtraHash -e1 but it said the module was not installed. So he wanted to install it from CPAN, which then offered to upgrade perl to perl-5.18.2.
It turns out Tie::ExtraHash is declared in the pm file of Tie::Hash and you should not use it on its own.
That set aside, wouldn't it be better if all the packages, at least in the Perl core, had their
own pm file with their own version number?
It certainly has some advantages.
BTW If you'd like to make sure in your code every package has its own pm file,
you can use the Perl::Critic policy Prohibit Multiple Packages in the same .pm file. It could be used to improved your code one policy at a time.
Though I disagree with enforcing a rigid policy of "one package per file", I do think that the various
Tie::*
classes distributed with Perl each deserve to be in a single pm file.My reasoning is that these classes are designed to be used as base classes for subclasses which do more interesting stuff; they're not really designed to be used in their own right. And the current situation breaks base.pm and parent.pm's assumptions. You can't for example do this:
Instead you must use some roundabout technique like:
Or even:
I'd go so far as saying that this is a bug in the
Tie::*
classes.Anything that can be used independently should be available in its own .pm file.
Modules that are just used as internal scaffolding for other things are fine appended to some other .pm file, but it shouldn't be in the index (i.e. its package declaration should be split up over multiple lines, or blocked from indexing with a meta no_index rule).
Indeed, this would make for a nice CPANTS/Kwalitee metric - every indexed (or indexable) module name Foo::Bar should be available in the corresponding Foo/Bar.pm file in the distribution.
Is there an important reason, why Tie::* does not have its own source distribution?
I would not go so far that this is a bug, but it is not best practice, not straight ahead design.
Tie::Handle seems repaired in a backwards compatible way. Why not the other Tie::* ones?
Tricky hiding things from a not-so-smart parser isn't a good solution.
Yes, it should be a CPANTS/Kwalitee metric. It compares to use strict, where also are good reasons in some cases for no strict.
> Tricky hiding things from a not-so-smart parser isn't a good solution.
This is a well-established way of signalling that a namspace should not be indexed. It's the only way to do it right in the code (without involving external metadata).