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

Re: FF:: namespace (was: New module: FLV file parsing)

Thread Previous | Thread Next
From:
Eric Wilhelm
Date:
December 3, 2005 14:54
Subject:
Re: FF:: namespace (was: New module: FLV file parsing)
Message ID:
200512031040.30170.ewilhelm@cpan.org
# from Smylers
# on Saturday 03 December 2005 03:41 am:

>That sounds tedious when written down like this, but basically it just
>involves holding down Ctrl and pressing P and X a few times.

Neat.  My vim does it all at once if the syntax mode is perl :-)

>> That said, I would much rather see all file-format parsing/writing
>> modules go under FileFormat:: than Parse::.
>
>But why group them under either?  Why group them at all?

Why group IO-related modules under IO:: ?  B:: ?  DBIx:: ?

Or, how is abbreviating FileFormat to FF bad and Input/Output to IO 
good?  Why is it a good idea for all-things-input/output to live under 
IO, but not for all-things-file-format to live under FF?  Seems like 
everyone who says FF means nothing would probably get used to it in 
less time than that consumed by this thread (and certainly less time 
than the cumulative value of typing "ile ormat".)  I'm very happy that 
chr is not character.  IMO, modules and CPAN are extensions of the 
language (I think that's even the literal definition or something :-)

>That's along the same lines of why I'd prefer CAD::, Graphics::,
>Video::, and whatever -- cos those are the sorts of modules that work
>together (even if only some of them are to do with file-types), rather
>than all the modules dealing with file-types.

My point about that is twofold:

  1)  Not all domains have a TLNS.  Some are just too obscure to really 
even need one.  Given that the first code to happen in a domain often 
involves accessing the data, the authors may have a hard time figuring 
out where that parser/writer should live.  Given an existing convention 
(however arbitrary it may be (though I would prefer it be a little of 
each "terse" and "logical")), they can just settle into the standard 
location.

  2)  Rooting a tree of file-format modules at FF:: allows 
all-things-file-format to be handled as a single entity (in your mind, 
on disk, in search engines, etc.)

So, now we have FLV::Info and whoever decides to make a single front-end 
that will read/write the FLV format will be shunned for using FLV.pm.  
Sad.

Maybe one day we'll be able to search for /^FF::\w+$/ and say "look at 
all of the file formats that I can access from Perl!"   Seems like 
something which looks that cool must have some sort of utility, but 
maybe it's just that I'm stuck in the cad/graphics world where all of 
our Smile Floormats form a disconnected proprietary/ open/ 
open-but-useless blob of "ugh" that keeps us from getting any real work 
done.  If that's the case, maybe the OP's module should go under 
Graphics::FF::FLV::Info?

--Eric
-- 
"You can't win. You can't break even. You can't quit."
--Ginsberg's Restatement of the Three Laws of Thermodynamics
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

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