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

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

Thread Previous | Thread Next
From:
Smylers
Date:
December 3, 2005 18:34
Subject:
Re: FF:: namespace (was: New module: FLV file parsing)
Message ID:
slrndp4ldr.1g0.Smylers@stripey.com
Eric Wilhelm writes:

> # 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 :-)

Ah, so it does.  That's because the default ftplugin/perl.vim sets
iskeyword to include the colon, so that all gets treated as a single
word.

It seems that I override that in my ~/.vim/after/ftplugin/perl.vim,
removing the colon, with a comment which says this is because with the
colon in iskeyword the interpolated variable name doesn't get
highlighted in qq-quoted strings like:

  print qq[$variable: with colon straight after it];

Until now I hadn't seen a disadvantage of removing that colon, but now
you've pointed that out I'm going to have to choose between putting up
with that bug in syntax highlighting or making namespaces more awkward
to complete ...

> > > 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:: ?

Those are are generally more generic, lower-level operations.  A module
for working with an AutoCad drawing has a much more specific and focused
use, and has almost nothing in common with a module for working with
Macromedia videos (or whatever).

> Or, how is abbreviating FileFormat to FF bad and Input/Output to IO
> good?

Because "IO", or at least "I/O", is a well-known abbreviation used
outside Cpan; it's the kind of term that is used in our office and
everybody knows what it means:

  http://en.wikipedia.org/wiki/I/O

Whereas we'd be synthesizing "FF" specifically for Cpan.

> Why is it a good idea for all-things-input/output to live under IO,

Actually not all input- and output-related things are under IO:: -- only
the generic fundamental modules are there.  Lots of other modules deal
with input or output in some way or other but are under a more specific
namespace.

> Seems like everyone who says FF means nothing would probably get used
> to it in less time than that consumed by this thread

There are also lots of people not on this list who would also have to
get used to it!

> (and certainly less time than the cumulative value of typing "ile
> ormat".)

Module names should be chosen for meaning, not purely shortness.

> > 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.
> 
>   1)  Not all domains have a TLNS.

Sure, but most modules are in _some_ field.

> 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
> they can just settle into the standard location.

Except that given that FF:: isn't particularly meaningful, FF::FLV is
almost as poor a name as just FLV.

>   2)  Rooting a tree of file-format modules at FF:: allows 
> all-things-file-format

But what are those things?  I still don't see what the situations are
where it's helpful to make this grouping!

> to be handled as a single entity (in your mind, on disk, in search
> engines, etc.)

I could see the benefit to that if FF:: were along the lines of
DateTime::Format:: where are lots of different modules for different
formats but they share a common interface, but not with lots of
completely independent modules.

Smylers
-- 
May God bless us with enough foolishness to believe that we can make a
difference in this world, so that we can do what others claim cannot be done.


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