# from David Landgren
# on Friday 02 December 2005 08:25 am:
>In about 10 days time, I'm going to forget utterly that FF means File
>Formats. Does it need to be so terse?
Considering the number of file formats which currently have toplevel
names, FF:: isn't that terse. Besides, search results should mean that
you _don't have to remember_ what FF means.
SVG
HTML
XML
PostScript (yeah, I know, let's pretend it's a "format")
PDF
Pdf (heh)
CSV
POD
ABI
CSS
GFL
VRML
YAML
File::Format::RIFF is of course misplaced if you consider what other
File:: modules do (typically fs queries/manipulation) and what
File::Format might do given the use of formats in printf (and/or what
the dos "format" command does :-)
Then there is the issue of tucking them away under whatever toplevel
namespace holds the domain with which that file format is associated
such as
Geo::GDAL
Text::xSV
Graphics::MNG
Image::PNGwriter
Apache::ConfigFile
In some of these cases, putting the module under a namespace of related
tools makes sense, but the problem is that the above two models are the
only thing that new authors have as examples. Either you blaze a trail
to a new TLNS or hide under an existing <mumble> (which may or may not
be completely unrelated to the file format.)
>Tossing out another suggestion with this in mind: Parse::File::FLV
But then we end up with Write::File::FLV ? Consider a distribution
which reads and writes a given binary format (I'll call it GBF.)
You want a parser, a writer, maybe a DOM, and/or a bit juggler, and
you'll definitely need some constants and of course someone will
eventually come along and write a ::Simple version. If we're going to
use Parse::, then I'll assume that writers live in Write:: (since
parsers are parsers, right?)
Parse::File::GBF - Front end to GBF read/write interface
Parse::File::GBF::Parser
Parse::File::GBF::Bytes
Parse::File::GBF::DOM
Parse::File::GBF::Constants
Parse::File::GBF::Simple
Write::File::GBF - just a directory under this model
Write::File::GBF::Simple
Write::File::GBF::Stream
But notice that Write::File::GBF probably requires
Parse::File::GBF::Constants, etc. It's rather unsettling.
Now consider the more comprehensible, discoverable single tree under
FF::
FF::GBF - Front end to GBF read/write interface
FF::GBF::Parser
FF::GBF::Bytes
FF::GBF::DOM
FF::GBF::Constants
FF::GBF::Writer
FF::GBF::Simple
FF::GBF::Writer::Stream
Does that sound better?
--Eric
--
"It is impossible to make anything foolproof because fools are so
ingenious."
--Murphy's Second Corollary
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
