Re: FF:: namespace (was: New module: FLV file parsing)
# from Daniel T. Staal # on Friday 02 December 2005 12:59 pm: It's better than the other examples, which doesn't mean it is good. How about FileFormat:: ? FileFormat::GBF - Front end to GBF read/write interface FileFormat::GBF::Parser ... Ok, but it's just SoooLoonng. I think Austin has a good point about searching. Once we can find a module, the name doesn't mean much _except_ when you're using it (be it daily or occasional coding.) I tend to detest the long names that too much discussion about hierarchy has forced on us... use My::Really::Long::Module::Name; my $obj = My::Really::Long::Module::Name-new(); ... is just _almost_ tedious enough to warrant copy/paste, but not quite. That said, I would much rather see all file-format parsing/writing modules go under FileFormat:: than Parse::. Yes, the search engine (while it may have to be google rather than search.cpan.org) can find things for us, but we don't want to need a search engine to remember the name of a familiar (ok, acquaintance) module. This also plays into managing an installed base of modules, distributing modules, etc. IMO, a distribution shouldn't have to break out of a single root. Starting with Parse, Info, ... means you're stuck (maybe just stuck looking silly, but still stuck.) FF:: is good for me, but I'll take FileFormat:: over Parse::, Info::, Flash::, QuantumPhysics::, etc. just to have a single TLNS for file-formats. --Eric -- ...the bourgeoisie were hated from both ends: by the proles, because they had all the money, and by the intelligentsia, because of their tendency to spend it on lawn ornaments. --Neal Stephenson --- http://scratchcomputing.com ---
Re: FF:: namespace (was: New module: FLV file parsing)
* Eric Wilhelm [EMAIL PROTECTED] [2005-12-03 11:05]:
I tend to detest the long names that too much discussion about
hierarchy has forced on us...
use My::Really::Long::Module::Name;
my $obj = My::Really::Long::Module::Name-new();
... is just _almost_ tedious enough to warrant copy/paste, but
not quite.
http://search.cpan.org/dist/aliased/ ?
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: FF:: namespace (was: New module: FLV file parsing)
On Fri, Dec 02, 2005 at 07:32:04PM -0800, Eric Wilhelm wrote: It's better than the other examples, which doesn't mean it is good. How about FileFormat:: ? FileFormat::GBF - Front end to GBF read/write interface FileFormat::GBF::Parser ... Ok, but it's just SoooLoonng. I think Austin has a good point about searching. Once we can find a module, the name doesn't mean much _except_ when you're using it (be it daily or occasional coding.) I tend to detest the long names that too much discussion about hierarchy has forced on us... use My::Really::Long::Module::Name; my $obj = My::Really::Long::Module::Name-new(); ... is just _almost_ tedious enough to warrant copy/paste, but not quite. Have you seen Package::Alias? That may help, if you end up typing it over and over. That said, I would much rather see all file-format parsing/writing modules go under FileFormat:: than Parse::. Yes, the search engine (while it may have to be google rather than search.cpan.org) can find things for us, but we don't want to need a search engine to remember the name of a familiar (ok, acquaintance) module. I have to do these sorts of things anyway, but I have a particularly bad memory. Is it Socket::INET? IO::Socket::Inet? IO::Socket::INET? Anyway, if you have a given module installed there should be some equivalent to `man -k` to find it. I'm not sure if there is, but there _should be_. This also plays into managing an installed base of modules, distributing modules, etc. IMO, a distribution shouldn't have to break out of a single root. Starting with Parse, Info, ... means you're stuck (maybe just stuck looking silly, but still stuck.) FF:: is good for me, but I'll take FileFormat:: over Parse::, Info::, Flash::, QuantumPhysics::, etc. just to have a single TLNS for file-formats. Well, Flash:: seems most sensible to me, but if I can find it, well, you know... Austin
Re: FF:: namespace (was: New module: FLV file parsing)
Eric Wilhelm writes: use My::Really::Long::Module::Name; my $obj = My::Really::Long::Module::Name-new(); ... is just _almost_ tedious enough to warrant copy/paste, but not quite. A decent editor should provide some sort of completion facility on previously typed terms, so that you don't have to retype them. For example in Vim having first typed: use My::Really::Long::Module::Name; you can then type: my $obj = M Pressing Ctrl+P (P for previous; you can guess what the keystroke for next is) completes this, incorrectly, to: my $obj = Module But simply keep Ctrl pressed and tap P a second time and you get: my $obj = My And from there press Ctrl+X Ctrl+P to type the word following the one you've just completed, giving: my $obj = My::Really Do that a few more times and you've got the whole name: my $obj = My::Really::Long::Module::Name That sounds tedious when written down like this, but basically it just involves holding down Ctrl and pressing P and X a few times. I believe that Emacs has an equivalent feature, and I'm sure I've seen some kind of tooltip completion feature on a gui Windows editor. Picking a decent editor and learning how to use it well is far better than trying to use unnaturally short identifiers throughout your code! 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? IMO, a distribution shouldn't have to break out of a single root. Starting with Parse, Info, ... means you're stuck (maybe just stuck looking silly, but still stuck.) 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. 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.
Re: FF:: namespace (was: New module: FLV file parsing)
* Smylers [EMAIL PROTECTED] [2005-12-03 12:45]:
I believe that Emacs has an equivalent feature
Yeah, that camp calls it hippie-expand – don’t ask.
and I'm sure I've seen some kind of tooltip completion feature
on a gui Windows editor.
That’s common.
Eclipse also offers “word completion,” which in previous versions
was called “hippie completion” and mimicked the emacs function.
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: FF:: namespace (was: New module: FLV file parsing)
# 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 ---
Re: FF:: namespace (was: New module: FLV file parsing)
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.
Re: FF:: namespace (was: New module: FLV file parsing)
# 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 ---
Re: FF:: namespace (was: New module: FLV file parsing)
On Fri, December 2, 2005 12:50 pm, Eric Wilhelm said: 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? It's better than the other examples, which doesn't mean it is good. How about FileFormat:: ? FileFormat::GBF - Front end to GBF read/write interface FileFormat::GBF::Parser FileFormat::GBF::Bytes FileFormat::GBF::DOM FileFormat::GBF::Constants FileFormat::GBF::Writer FileFormat::GBF::Simple FileFormat::GBF::Writer::Stream Now you know just by looking at it what it means: GBF is a file format, and we have a parser, writer, stream, etc. for that format. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
Re: FF:: namespace (was: New module: FLV file parsing)
On Fri, Dec 02, 2005 at 09:50:19AM -0800, Eric Wilhelm wrote: # 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. This is a good point, and sort of what I was thinking: If it can be found via search, who care's what it's called? It's sort of like domain names - once upon a time people might have thought to remember the name of a website, but now, who bothers? Just pop what you want in google... As long as the name isn't taken and it has some amount of logic, I doubt the name of a module makes any practical difference any more. It seems like the days of poring over proper module names should come to an end. *shrug* Just a thought. Austin
Re: FF:: namespace (was: New module: FLV file parsing)
On Fri, Dec 02, 2005 at 03:31:48PM -0600, David Nicol wrote: On 12/2/05, Austin Schutz [EMAIL PROTECTED] wrote: As long as the name isn't taken and it has some amount of logic, I doubt the name of a module makes any practical difference any more. It seems like the days of poring over proper module names should come to an end. *shrug* Just a thought. Austin hmmm maybe I'll do like Jonothan Borofsky (http://www.borofsky.com/numbers.htm) and just number my modules from now on I think the interpreter might complain about that a bit- use 22; Perl v22.0.0 required (did you mean v22.000?)--this is only v5.8.6, stopped at -e line 1. :-) Austin
Re: FF:: namespace (was: New module: FLV file parsing)
I think the interpreter might complain about that a bit- use 22; Perl v22.0.0 required (did you mean v22.000?)--this is only v5.8.6, stopped at -e line 1. :-) Austin # perl -MModuleNumber22 -le 'print 1' Can't locate ModuleNumber22.pm in @INC (@INC contains: but maybe the series would better start at MN1 or maybe MNa so the name is more terse
Re: FF:: namespace (was: New module: FLV file parsing)
Sorry, that should have been $ perl -MModuleNumber::22 -le 'print 1' Can't locate ModuleNumber/22.pm in @INC
