develooper Front page | perl.module-authors | Postings from December 2005

Re: New module: FLV file parsing

Thread Previous | Thread Next
From:
Austin Schutz
Date:
December 3, 2005 02:16
Subject:
Re: New module: FLV file parsing
Message ID:
20051203101536.GD28489@gblx.net
On Sat, Dec 03, 2005 at 08:30:20AM +0000, Smylers wrote:
> There are several places where somebody could first encounter a module
> name:
> 
> > 	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?
> 
> A large search results listing is one such place.  You want to be able
> to pick out the potentially useful modules from the list, so having
> their names be as meaningful as possible helps with this.
> 

	If the module description is included the actual name provides
some debatable amount of additional benefit. FF:: is a good example. Yes, I
agree that it effectively has no meaning, other than an implication that one
FF:: module may be related to other FF:: modules. But I disagree that it
matters a great deal in the modern CPAN.
	One wants to parse FLV files, the module description says it
does that. It could be FileFormat::FLV, FLV::File, Parser::FLV, Flash::FLV,
Video::FLV, etc., and it should make little difference as long as the
description is concise, descriptive, and accurate.

> > No. I concur that the module name is effectively meaningless,
> 
> Since "FF" is meaningless, why bother including it at all?  It's just
> noise.
> 
	For two reasons - grouping of related modules under the FF:: heading,
and to avoid the top level issue you state below.

> > but I don't see that it makes any difference to the searcher.
> 
> I'm much more likely to spend time investigating modules whose names I
> can understand.  I suspect I'm not alone on that.
> 
> > 	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,
> 
> That's a second place module names are encountered, and I'd say that's beyond
> marginal.  Lots of code is read by people other than the original author, and
> it's good if the approximate use of a module is guessable just from the
> calling code.
> 

	Yes, I agree, but would emphasize "approximate".

> > but beyond that, what tangible and practical difference does it make?
> 
> Another place I encounter module names is the RSS feed for Cpan uploads; I'm
> interested in seeing what sort of things people are making available, and
> looking out for things that are of interest.  There are also feeds for
> AnnoCpan and Cpan Ratings -- if you see a comment on or a review of a module
> it's better if you know vaguely what the module is about (or at least if can
> see what field it's in, so you can dismiss it if it isn't anything of
> interest to you).
> 
> People mention modules at PerlMonks, on mailing lists, and in the pub at Perl
> Mongers meetings and conferences.  In all of these places a meaningful name
> helps everybody identify the module being discussed.
> 
> Or to put it another way round: if a meaningful name is available, what's the
> advantage of going out of your way to pick an acknowledged meaningless one?
> 

	I have not suggested "going out of your way" to pick a meaningless
one. In this case, the author picked FLV::Info. I don't see how the
discussion to change this to something like FileFormat::FLV has made the
name so much more intuitive as to have made this list's bandwidth worthwhile.

	For a given entry (search result, browse page, etc.), the description
of the module should be included with the name - again, for example:

FLV::Info - Extract metadata from Flash Video files

	as compared to

FileFormat::FLV - Extract metadata from Flash Video files

	I don't see how these naming adjustments are so much more practical as
to warrant the module authors list bandwidth any longer.

	At one time, when the module list was much smaller and there was no
search facility, naming was very important.  But with the vast size of the
modern CPAN and the addition of searching capabilities, the focus of effort on
detailed module naming seems outdated, at least for this particular mailing
list.

> > > If that  were true, the practice of bouncing name ideas off this email
> > > list  would cease, and I'd just name it FLV.pm.
> > 
> > 	As I understand it there's some rationale for keeping the top level
> > 	namespace small, so that would probably not be a good choice.
> 
> Almost.  I think that it's cos if you call it FLV it's effectively claiming
> to be _the_ module for FLV.  It's more future proof to call it
> FLV::Something, anticipating other people contributing FLV::SomethingElse
> later.
> 
> Unfortunately there seems to be a meme going round where the advice not to
> use a single-level name for a module has morphed into not using a multi-level
> name where the first level is new.
> 

	Ok, that makes sense. I knew there was a reason. :-)

> > 	I submit these long threads about which module name is better than some
> > 	other similar name are a waste of time,
> 
> If you don't care what modules are called then don't participate in them!  By
> definition whatever a module ends up being called you will be satisified!  If
> some of the rest of us (including a modules' author) are fussy it doesn't
> make module names worse for you ...
> 

	No, it certainly does not affect me negatively to have a more intuitive
module name. But I believe the ongoing debates reduce the utility of the module
authors mailing list, and therein lies my concern. If there were a separate
mailing list dedicated to module naming those concerned with proper names could
debate to their satisfaction and allow the authors list to concentrate on other
module related issues.

	Would that be an equitable solution?

	Austin

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About