# from Daniel T. Staal
# on Friday 02 December 2005 12:59 pm:
>It's better than the other examples, which doesn't mean it is good.
> How about FileFormat:: ?
>
>FileFormat::GBF - Front end to GBF read/write interface
>FileFormat::GBF::Parser
>...
Ok, but it's just SoooLoonng.
I think Austin has a good point about searching. Once we can find a
module, the name doesn't mean much _except_ when you're using it (be it
daily or occasional coding.)
I tend to detest the long names that too much discussion about hierarchy
has forced on us...
use My::Really::Long::Module::Name;
my $obj = My::Really::Long::Module::Name->new();
... is just _almost_ tedious enough to warrant copy/paste, but not
quite.
That said, I would much rather see all file-format parsing/writing
modules go under FileFormat:: than Parse::. Yes, the search engine
(while it may have to be google rather than search.cpan.org) can find
things for us, but we don't want to need a search engine to remember
the name of a familiar (ok, acquaintance) module.
This also plays into managing an installed base of modules, distributing
modules, etc. IMO, a distribution shouldn't have to break out of a
single root. Starting with Parse, Info, ... means you're stuck (maybe
just stuck looking silly, but still stuck.)
FF:: is good for me, but I'll take FileFormat:: over Parse::, Info::,
Flash::, QuantumPhysics::, etc. just to have a single TLNS for
file-formats.
--Eric
--
"...the bourgeoisie were hated from both ends: by the proles, because
they had all the money, and by the intelligentsia, because of their
tendency to spend it on lawn ornaments."
--Neal Stephenson
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
