Re: New module: FLV file parsing
A. Pagaltzis writes: * Smylers [EMAIL PROTECTED] [2005-12-02 22:10]: Eric Wilhelm writes: I'm working on CAD::DXF for now, Cad is a well-known acronym. I have no use for anything cad-related in my life at the moment, so I know that I can safely ignore that module. But as it happens, referring to DXF in the context of cad is enough to prompt me into recollecting that .dxf is an AutoCad file extension. Are we reinventing MIME types now? No. Mime media types only apply to file formats; Cpan modules cover much more than that. Let?s just stick with Process::video::x_flv Process::application::x_shockwave_flash Process::image::x_dxf Snip But that's still grouping together all file-format-related modules (under Process::), rather than grouping them by function. It does make sense for CAD::DXF and CAD::Calc to be in the same namespace as each other, and grouping all the file-format modules together prevents that from happening, whether it's the truly awful FF:: or the mostly meaningless Process:: (surely nearly all Cpan modules perform some kind of processing?). DateTime::Format::Mail is a good name for a module; you can see that it is part of the DateTime project and is for processing dates as used in e-mails. Naming it Process::RFC822::DateTime (or similar) is not an improvement. 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: New module: FLV file parsing
Austin Schutz writes: On Fri, Dec 02, 2005 at 04:04:11PM -0600, Chris Dolan wrote: The FF:: namespace is a terrible idea, in my opinion. I expect that it will be meaningless to the majority of module searchers. The argument that search makes names irrelevant is just silly. ..because? There are several places where somebody could first encounter a module name: Ok, I want to do something with my flash file. I search for 'flash file'... Oh look, there's a flash file parser. Do I care what it's called? A large search results listing is one such place. You want to be able to pick out the potentially useful modules from the list, so having their names be as meaningful as possible helps with this. No. I concur that the module name is effectively meaningless, Since FF is meaningless, why bother including it at all? It's just noise. but I don't see that it makes any difference to the searcher. I'm much more likely to spend time investigating modules whose names I can understand. I suspect I'm not alone on that. It's marginally helpful to have a useful name when including it in a module so code doesn't look like $flv = new ASDFsdafs::sjhsdlk, That's a second place module names are encountered, and I'd say that's beyond marginal. Lots of code is read by people other than the original author, and it's good if the approximate use of a module is guessable just from the calling code. but beyond that, what tangible and practical difference does it make? Another place I encounter module names is the RSS feed for Cpan uploads; I'm interested in seeing what sort of things people are making available, and looking out for things that are of interest. There are also feeds for AnnoCpan and Cpan Ratings -- if you see a comment on or a review of a module it's better if you know vaguely what the module is about (or at least if can see what field it's in, so you can dismiss it if it isn't anything of interest to you). People mention modules at PerlMonks, on mailing lists, and in the pub at Perl Mongers meetings and conferences. In all of these places a meaningful name helps everybody identify the module being discussed. Or to put it another way round: if a meaningful name is available, what's the advantage of going out of your way to pick an acknowledged meaningless one? If that were true, the practice of bouncing name ideas off this email list would cease, and I'd just name it FLV.pm. As I understand it there's some rationale for keeping the top level namespace small, so that would probably not be a good choice. Almost. I think that it's cos if you call it FLV it's effectively claiming to be _the_ module for FLV. It's more future proof to call it FLV::Something, anticipating other people contributing FLV::SomethingElse later. Unfortunately there seems to be a meme going round where the advice not to use a single-level name for a module has morphed into not using a multi-level name where the first level is new. I submit these long threads about which module name is better than some other similar name are a waste of time, If you don't care what modules are called then don't participate in them! By definition whatever a module ends up being called you will be satisified! If some of the rest of us (including a modules' author) are fussy it doesn't make module names worse for you ... 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: New module: FLV file parsing
* Smylers [EMAIL PROTECTED] [2005-12-03 09:20]: But that's still grouping together all file-format-related modules (under Process::), rather than grouping them by function. I was not being serious. :-) Regards, -- Aristotle “If you can’t laugh at yourself, you don’t take life seriously enough.”
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: New module: FLV file parsing
On Sat, Dec 03, 2005 at 08:30:20AM +, Smylers wrote: There are several places where somebody could first encounter a module name: Ok, I want to do something with my flash file. I search for 'flash file'... Oh look, there's a flash file parser. Do I care what it's called? A large search results listing is one such place. You want to be able to pick out the potentially useful modules from the list, so having their names be as meaningful as possible helps with this. If the module description is included the actual name provides some debatable amount of additional benefit. FF:: is a good example. Yes, I agree that it effectively has no meaning, other than an implication that one FF:: module may be related to other FF:: modules. But I disagree that it matters a great deal in the modern CPAN. One wants to parse FLV files, the module description says it does that. It could be FileFormat::FLV, FLV::File, Parser::FLV, Flash::FLV, Video::FLV, etc., and it should make little difference as long as the description is concise, descriptive, and accurate. No. I concur that the module name is effectively meaningless, Since FF is meaningless, why bother including it at all? It's just noise. For two reasons - grouping of related modules under the FF:: heading, and to avoid the top level issue you state below. but I don't see that it makes any difference to the searcher. I'm much more likely to spend time investigating modules whose names I can understand. I suspect I'm not alone on that. It's marginally helpful to have a useful name when including it in a module so code doesn't look like $flv = new ASDFsdafs::sjhsdlk, That's a second place module names are encountered, and I'd say that's beyond marginal. Lots of code is read by people other than the original author, and it's good if the approximate use of a module is guessable just from the calling code. Yes, I agree, but would emphasize approximate. but beyond that, what tangible and practical difference does it make? Another place I encounter module names is the RSS feed for Cpan uploads; I'm interested in seeing what sort of things people are making available, and looking out for things that are of interest. There are also feeds for AnnoCpan and Cpan Ratings -- if you see a comment on or a review of a module it's better if you know vaguely what the module is about (or at least if can see what field it's in, so you can dismiss it if it isn't anything of interest to you). People mention modules at PerlMonks, on mailing lists, and in the pub at Perl Mongers meetings and conferences. In all of these places a meaningful name helps everybody identify the module being discussed. Or to put it another way round: if a meaningful name is available, what's the advantage of going out of your way to pick an acknowledged meaningless one? I have not suggested going out of your way to pick a meaningless one. In this case, the author picked FLV::Info. I don't see how the discussion to change this to something like FileFormat::FLV has made the name so much more intuitive as to have made this list's bandwidth worthwhile. For a given entry (search result, browse page, etc.), the description of the module should be included with the name - again, for example: FLV::Info - Extract metadata from Flash Video files as compared to FileFormat::FLV - Extract metadata from Flash Video files I don't see how these naming adjustments are so much more practical as to warrant the module authors list bandwidth any longer. At one time, when the module list was much smaller and there was no search facility, naming was very important. But with the vast size of the modern CPAN and the addition of searching capabilities, the focus of effort on detailed module naming seems outdated, at least for this particular mailing list. If that were true, the practice of bouncing name ideas off this email list would cease, and I'd just name it FLV.pm. As I understand it there's some rationale for keeping the top level namespace small, so that would probably not be a good choice. Almost. I think that it's cos if you call it FLV it's effectively claiming to be _the_ module for FLV. It's more future proof to call it FLV::Something, anticipating other people contributing FLV::SomethingElse later. Unfortunately there seems to be a meme going round where the advice not to use a single-level name for a module has morphed into not using a multi-level name where the first level is new. Ok, that makes sense. I knew there was a reason. :-) I submit these long threads about which module name is better than some other similar name are a waste of time, If you don't care what modules are called then don't participate in them! By definition whatever a module ends up being called you will be satisified!
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: New module: FLV file parsing
Austin Schutz writes: On Sat, Dec 03, 2005 at 08:30:20AM +, Smylers wrote: [Austin wrote:] Do I care what it's called? A large search results listing is one such place. You want to be able to pick out the potentially useful modules from the list, so having their names be as meaningful as possible helps with this. If the module description is included the actual name provides some debatable amount of additional benefit. But module names tend to be headings, what draw your attention in first. Yes, descriptions often help to clarify things, but a good name is obviously more useful than a poor one. Sometimes it's hard to find a name that is intuitive, but there doesn't seem to be any point in choosing to 'waste' part of the name on an abbreviation that nobody at all thinks is meaningful. FF:: is a good example. ... it should make little difference as long as the description is concise, descriptive, and accurate. You say If ... above. Not everywhere that mentions a module name has its description next to it (in code, for example). In the same way that it's better to code clearly without comments, than to code obscurely and have to add comments explaining what you mean, it's helpful for module names to be clear even without their descriptions. Since FF is meaningless, why bother including it at all? It's just noise. For two reasons - grouping of related modules under the FF:: heading, But I'm claiming that they _aren't_ related merely by being file formats. The fact that they are file formats isn't the most relevant thing about them. and to avoid the top level issue you state below. Except that I pointed out that this isn't an issue: it's a meme that has been misinterpreted from what the advice on Pause says. There in general isn't a problem with inventing a new top-level namespace for a new category of modules. What's frowned upon is giving a module only a single-level name. So hogging FLV is antisocial, but opening up FLV:: by using FLV::Something is perfectly acceptable, even encouraged. it's good if the approximate use of a module is guessable just from the calling code. Yes, I agree, but would emphasize approximate. Right, so let's try to make module names as meaningful as possible, and not include meaningless bits in them. Or to put it another way round: if a meaningful name is available, what's the advantage of going out of your way to pick an acknowledged meaningless one? I have not suggested going out of your way to pick a meaningless one. I'd claim that renaming FLV::Info to FF:FLV would be -- the module already has one name and changing it would be putting effort in to including the term FF, which everybody agrees is meaningless. I believe the ongoing debates reduce the utility of the module authors mailing list, and therein lies my concern. If there were a separate mailing list dedicated to module naming those concerned with proper names could debate to their satisfaction and allow the authors list to concentrate on other module related issues. Would that be an equitable solution? I wouldn't object to it, but I suspect it isn't worth the hassle of setting it up (and that having 2 lists would just add to the levels of confusion, and people would end up posting the 'wrong' sort of question to each list anyway). This mailing list isn't very high traffic as it is. Nearly all participants are using decent mail or news clients, such that proper threading is preserved. This makes it relatively easy to avoid an entire thread that you're not interested in -- there have been plenty of threads here that I've skipped cos they don't happen to be my kind of thing, but I don't doubt that this is a good place for them to exist. 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)
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: New module: FLV file parsing
# from A. Pagaltzis # on Friday 02 December 2005 02:45 pm: Process::video::x_flv Process::application::x_shockwave_flash Process::image::x_dxf Process::audio::mpeg Process::image::png Process::text::html That's great! Problem solved. Process::application::x_shockwave_flash::FLV::Info Why didn't I think of that earlier? So much easier to type than FF::. --Eric -- But as to modern architecture, let us drop it and let us take modernistic out and shoot it at sunrise. --F.L. Wright --- http://scratchcomputing.com ---
CPAN Upload: A/AN/ANDK/CPAN-1.80.tar.gz
I'm pleased to announce the upload of a new CPAN release 1.80. Thanks to all involved people, especially those who didn't make it into the releasenotes. I hope you have the appropriate amount of fun or a least not too many annoying encounters with it. Thank you. Releasenotes * support for Module::Signature courtesy Autrijus Tang * separated out new module CPAN::Version that has muchly improved support for multidot version notation that should make the deployment of version.pm easy for everybody. During the last weeks the indexer on PAUSE also got improved version.pm support and spits out numified versions. This release is optimized for the new version handling, regardless if used with or without version.pm (Thanks to John Peacock and to Graham Barr for their help) * new pragma 'notest' courtesy Slaven Rezic * support for sudo in the config variable 'make_install_make_command' courtesy Michael Richardson * new commands 'recent' and 'perldoc' courtesy Toni Prug * improved wget support for Windows users courtesy Daniel * cleanup internal use of CPAN::Frontend courtesy David Storrs * fixes to distro bugs by Adriano Ferreira * runs under 5.004_05 courtesy Sébastien Aperghis-Tramoni * new feature 'show_upload_date': if set to true, all 'm' and 'd' commands will display the upload date * fix bug in FirstTime causing endless loop under some conditions * better completion for config variables and a new warning if an unregistered config variable is being set * improved some error messages * improved help menu (Thanks to David Golden for the suggestion) Start of forwarded message The uploaded file CPAN-1.80.tar.gz has entered CPAN as file: $CPAN/authors/id/A/AN/ANDK/CPAN-1.80.tar.gz size: 161796 bytes md5: a74010be23bbad72919e3850a0ae73e1 No action is required on your part Request entered by: ANDK (Andreas J. König) Request entered on: Sat, 03 Dec 2005 10:10:06 GMT Request completed: Sat, 03 Dec 2005 10:12:08 GMT Thanks, -- paused, v460 End of forwarded message -- andreas
Re: New module: FLV file parsing
On Dec 2, 2005, at 4:20 PM, Austin Schutz wrote: On Fri, Dec 02, 2005 at 04:04:11PM -0600, Chris Dolan wrote: The FF:: namespace is a terrible idea, in my opinion. I expect that it will be meaningless to the majority of module searchers. The argument that search makes names irrelevant is just silly. ..because? Ok, I want to do something with my flash file. I search for 'flash file'... Oh look, there's a flash file parser. Do I care what it's called? No. I concur that the module name is effectively meaningless, but I don't see that it makes any difference to the searcher. Nitpick: FLV is not Flash. FLV is a video format that is often used by Flash movies, but it is not Flash and does not work standalone without a Flash movie to control it. SWF is the file format for Flash movies. It's marginally helpful to have a useful name when including it in a module so code doesn't look like $flv = new ASDFsdafs::sjhsdlk, but beyond that, what tangible and practical difference does it make? You assume that all authors discover modules solely through search.cpan.org? I often discover modules by reading other people's code and seeing what modules they use. If I see use FF::FOOBAR at the top of someone's module, I will have no idea what they are trying to do. But if I see, say FileFormat::Video::FOOBAR then at least I will know the author is trying to interact with a stream of video data. To me, it's as much about readable code as it is about findable modules. If that were true, the practice of bouncing name ideas off this email list would cease, and I'd just name it FLV.pm. As I understand it there's some rationale for keeping the top level namespace small, so that would probably not be a good choice. Beyond that, name it what you will. I submit these long threads about which module name is better than some other similar name are a waste of time, and I do indeed suggest we take them off list as a general rule. Austin I strongly disagree. I think good naming is important for readability and maintainability. Like good variable and method names, module names should be self-documenting whenever feasible. Since module names are harder to change than variable or method names, I say a little forethought and discussion is justified. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Module naming mailing list? Was: Re: New module: FLV file parsing
--- Austin Schutz [EMAIL PROTECTED] wrote: Ok, you and a few other vocal people have very strong opinions about this, which I don't begrudge you. Can we move the discussions to a different list? While I certainly agree that long discussions about how to name modules get tedious after a while, discussions of what modules do and what modules should be named are so intertwined that we'd be forced to bounce back and forth between the lists. The first thing that would happen on a module naming list would be someone asking well, what does your module do? That's often followed by there's already a module which does that or maybe it should do X instead. Then that conversation would legitimately jump back here and would eventually jump to the naming list ... over and over again. That would be even more tedious (hard to believe, I know). Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Module naming mailing list? Was: Re: New module: FLV file parsing
# from Ovid # on Saturday 03 December 2005 12:22 pm: Then that conversation would legitimately jump back here and would eventually jump to the naming list ... over and over again. That would be even more tedious (hard to believe, I know). And eventually everyone in the thread (except the list, because of course the list doesn't want to hear about _foo_) would just be getting CC'd on every message and each thread would become its own little ad-hoc mailing list. Sounds like a plan. --Eric -- If the collapse of the Berlin Wall had taught us anything, it was that socialism alone was not a sustainable economic model. --Robert Young --- http://scratchcomputing.com ---
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: Module naming mailing list? Was: Re: New module: FLV file parsing
On Sat, Dec 03, 2005 at 12:22:16PM -0800, Ovid wrote: --- Austin Schutz [EMAIL PROTECTED] wrote: Ok, you and a few other vocal people have very strong opinions about this, which I don't begrudge you. Can we move the discussions to a different list? While I certainly agree that long discussions about how to name modules get tedious after a while, discussions of what modules do and what modules should be named are so intertwined that we'd be forced to bounce back and forth between the lists. The first thing that would happen on a module naming list would be someone asking well, what does your module do? That's often followed by there's already a module which does that or maybe it should do X instead. Then that conversation would legitimately jump back here and would eventually jump to the naming list ... over and over again. That would be even more tedious (hard to believe, I know). Yeah, I don't have an answer for this, and with the level of importance some give detailed and debated naming, I guess we're stuck with it. Bring on the nits, let's get splitting. Austin
