On Fri, Dec 02, 2005 at 06:10:15PM -0600, John M. Gamble wrote:
> >>The FF:: namespace is a terrible idea, in my opinion. I expect that
> >>it will be meaningless to the majority of module searchers. The
> >>argument that search makes names irrelevant is just silly.
> >>
> >>
> >
> > ..because?
> >
> > Ok, I want to do something with my flash file. I search for
> >'flash file'... Oh look, there's a flash file parser. Do I care what it's
> >called? No. I concur that the module name is effectively meaningless, but I
> >don't see that it makes any difference to the searcher.
> >
> >
>
> Two bad assumptions here: 1) the searcher always knows what words to
> search for, and 2) searching is an acceptable substitute for browsing.
>
> In this case of course, 'flash' is pretty obvious and searching for it
> should give one everything on CPAN, but in other cases this might not be
> true. For example, I had a little trouble with the RSS and Atom
> distinction, and had I been even more ignorant, I might have missed some
> useful modules.
If you search for RSS and Atom, and don't find something which
approximates that being searched for, then either the searching mechanism
needs work (which I'm sure it does), the module has not been appropriately
documented, or you may need to choose additional or better keywords for
searching. Let's use Info::FLV as an example:
NAME
FLV::Info - Extract metadata from Flash Video files
Any searches for FLV, info, extract, metadata, flash, video, and
file[s] should return a link to this module. Multiple hits should be
prioritized higher. Typical search behavior. If the engine doesn't do this,
the engine needs work.
>
> Taking the other side of the coin, browsing is much more useful when the
> module has a name that can catch the eye.
While I would suggest browsing is generally less useful than searching,
this may be partially true. However, browsing is inherently a hierarchical
behavior, and the hierarchy the author may choose to place their module in may
not match what you expect - especially if it is a name based hierarchy.
Case in point: is FLV::Info a file manipulating module, a video
processing related module, or a Flash related module? It is clearly all three.
Placing it in some sort of hierarchy based solely upon one aspect of the module
may make it appear unrelated to similar or complementary modules placed
somewhere else in the hierarchy.
> Right now we only have two
> 'browsing' modes in CPAN, the Recent Arrivals list, and the
> all-but-useless Module List Chapter. I'd like to see true browsing,
> arranged in a tree structure (e.g., a list of top level names that one
> could click on, which would bring up a list of the
> TopLevelName::NextLevelNames, and so on). Granted that I'm using a
> non-existent feature [1] to demonstrate a point, but just how useful would
> an FF top level name be in this situation?
>
If you must have some sort of browsing frontend, it should be something
akin to keyword based, so it will be seen in all appropriate places.
If you are suggesting a new "module list" which would take these
into account, I wouldn't dissuade you from it. I'm sure many people would
find it useful, or at very least interesting.
>
> > It's marginally helpful to have a useful name when including it
> >in a module so code doesn't look like $flv = new ASDFsdafs::sjhsdlk, but
> >beyond that, what tangible and practical difference does it make?
> >
> Choosing meaningful variable names in your code is considered good
> programming practice. Why wouldn't it be an equally good practice for
> naming modules?
>
Yes, certainly it would. But to a certain degree it's the
responsibility of the reader to determine what a module might mean. _Any_ of
the suggestions I've seen for the name of this particular module would suffice,
because when it's in code there is a context for the name (and hopefully
comments) which indicate how it is used. Any further confusion is remedied
by looking at `perldoc Module`, or the equivalent.
I'm not suggesting completely random names, but I don't see any
genuinely useful reason to discuss them in committee any longer. The author has
a good enough idea what a module does to be able to name it sensibly enough for
practical usage.
Austin
