I dislike Perl's lib/Module.pm AND lib/Module/SubModule.pm

I dislike how Perl requires modules, and the submodules which are really "internal" to them, to live in two places in the filesystem - even if those places are right next to each other.

E.g. the module's top level code in some lib/Module.pm

And the code for any submodules that are really part of the module in the directory tree under lib/Module, e.g. lib/Module/SubModule.pm

So you cannot simply operate on one filesusem object for the module: e.g.g you cannot do:

mv lib/Module some-other-lib-path/Module

Instead, you must do

mv lib/Module.pm some-other-lib-path/Module.pm
mv lib/Module.pm some-other-lib-path/Module.pm 

A minor difference, two commands rather than one, something that can odten be patched over by regexps.

But an important difference: I would go so far as to say that the representation of Perl modules (classes) in the filesystem is not object oriented.  I would say that one of the key characteristics of an object, in this class treating the code for a class as an object, is that it behaves like it is a single object, unless explicitly opened up to look inside.

---+ Bad Influence on Perl CPAN class structure

I think this decision, to have lib/Module.pm and lib/Module/SubModule.pm, has had a bad, or at least confusing, influence on CPAN's module structure.

Sometimes a CPAN module Foo::Bar (lib/Foo/Bar.pm) is actually a module completely unrelated[*] to module Foo (lib/Foo.pm). More confusing if module Foo actually has some internal modules Foo::Fu (lib/Foo/Fu.pm).

(Note *: OK, not "completely unrelated".  How about "unrelated wrt code structure", or "related only by topic, but not actual code".)

Then there is no localization of Foo in the filesystem.   Some parts of lib/Foo are part of module Foo, and some are not.   And not everthing in module Foo is under lib/Foo.

I.e. the Perl CPAN filesystem structure sometimes reflects module structure, and sometimes it just reflects theme.

---+ Kluges

For this reason, I often make my modules appear as Foo::Foo, i.e. lib/Foo/Foo.pm.

But this can become tiresome.  Tiresome. Repetitious.  And it does not prevent somebody else from defining Foo::Bar, and wanting to live in the same directory tree (if not in separate PATH elements).

So I might try Topic::Long_Module_Name_Unlikely_To_Conflict::Short_Module_Name

i.e.
      lib
           /TopicLong_Module_Name_Unlikely_To_Conflict
               /Short_Module_Name.pm
               /Short_Module_Name/Sub_Modules...

e.g.  lib/Foo/AG_Foobar/Foo.pm

Not ideal.

Similarly, I might use a level of indirection to group internal submodules

Foo::internal::Submodules
vs
Foo::Unrelated_Submodules

Again, not ideal.    

---+ What is really needed

Modules should correspond to subtrees of the filesystem.

e.g. lib/Foo.pm, if no furter structure.

lib/Foo.pmdir/Foo.pm  if submodules such as lib/Foo.pmdir/Sub.pm

with it being an error to have both lib/Foo.pm and lib/Foo.pmdir exist.

Or, if you will, require the indirection even if no further structure: lib/Foo.pmdir/Foo.pm, and never lib/Foo.pm

The main file might be called lib/Foo/main.pm.  But I rather like lib/Foo/Foo.pm, or lib/Foo.pmdir/Foo.pm

---+ References

use - perldoc.perl.org: <>

require - perldoc.perl.org: <The require function will actually look for the "Foo/Bar.pm" file in the directories specified in the @INC array.>>



'via Blog this'