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.
