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 ---
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
Re: New module: FLV file parsing
Eric Wilhelm wrote: # from David Nicol # on Wednesday 30 November 2005 02:18 pm: isn't there a multimedia name space? name spaces per-product that is being supported make sense --- Flash::parseFLV perhaps? What else will appear in the Flash:: namespace? Will macromedia release a pure perl version? What all file format parsers and dumpers have in common is that they deal with File Formats. In a lot of cases, the only module that is going to be created is for that format. I'm working on CAD::DXF for now, but would rather name it FF::DXF, similarly with FF::SVG, FF::XAR, FF::PDF, etc. FF::FLV sounds best to me. In about 10 days time, I'm going to forget utterly that FF means File Formats. Does it need to be so terse? Tossing out another suggestion with this in mind: Parse::File::FLV David -- It's overkill of course, but you can never have too much overkill.
Re: New module: FLV file parsing
On 12/2/05, David Landgren [EMAIL PROTECTED] wrote: Eric Wilhelm wrote: What else will appear in the Flash:: namespace? Will macromedia release a pure perl version? In about 10 days time, I'm going to forget utterly that FF means File Formats. Does it need to be so terse? Tossing out another suggestion with this in mind: Parse::File::FLV The flood of modules that also pertain to manipulating flash files, now that Pagaltzis has smashed the levy. God only knows what they might look like. Flash::import::gif::animated, Flash::import::pdf, Flash::Dancer. -- David L Nicol Which is better, to burn out or to fade away? Refer to authorities from classical Roman, Greek and Chinese thought in your answer.
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: New module: FLV file parsing
Eric Wilhelm writes: # from David Nicol # on Wednesday 30 November 2005 02:18 pm: isn't there a multimedia name space? ame spaces per-product that is being supported make sense --- Flash::parseFLV perhaps? What else will appear in the Flash:: namespace? It doesn't matter if nothing else appears there -- the module would still have a name that's readily understandable. What all file format parsers and dumpers have in common is that they deal with File Formats. Yes, but that isn't more relevant than the particular file format each deals with. For example, I'd be much more likely to first think that I'd be working with Flash files, and then realize that I need to parse them, than to start by thinking that I'm working with files that have a format, and only then that the format is Flash. In a lot of cases, the only module that is going to be created is for that format. And that causes what harm? 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. but would rather name it FF::DXF, Whereas if I saw that I wouldn't know what either set of letters mean; DXF is sufficiently meaningful in my brain to make me think of AutoCad without any context. And FF could be one of many things: recently I've seen it used to abbreviate Firefox in quite a few places; if I'd just been reading some music (or trying to solve a crossword) I might think of it meaning very loud. similarly with FF::SVG, FF::XAR, FF::PDF, etc. What does that achieve? Putting all the cad-related modules makes good sense to me, and similarly for other things. FF::FLV sounds best to me. I wouldn't have a clue what that means. I hadn't heard of FLV before this thread, and I wouldn't guess FF without this thread either. With Flash::FLV I still wouldn't know what FLV stands for, but I'd have a clue as to its context -- enough of a clue to know whether I'm interested in investigating the module further if it I see it in the 'recent uploads' list. 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)
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
Re: New module: FLV file parsing
On Fri, Dec 02, 2005 at 04:04:11PM -0600, Chris Dolan wrote: So, I already published it as FLV::Info, but this discussion has convinced me that FileFormat::FLV is the best option. I may use that name for v0.02. My only hesitation is that nobody else seems to be using that top-level namespace at this time. 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. 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? 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
Re: New module: FLV file parsing
Chris Dolan writes: So, I already published it as FLV::Info, but this discussion has convinced me that FileFormat::FLV is the best option. I still don't see what's to be gained from having all modules that deal with specific file-formats grouped together -- or more specifically why that makes more sense than grouping them in Cad:: or Graphics:: or Spreadsheet:: or whatever else they are actually useful for. The FF:: namespace is a terrible idea, in my opinion. Ditto. I expect that it will be meaningless to the majority of module searchers. Exactly -- even if you search by FLV, seeing FF::FLV in the results list doesn't help you at all. As for the Flash:: namespace, I don't think that's best. While FLV is primarily used in the Macromedia Flash Player ... However it's preferable for module names to be 'best fit' rather than 'pedantically accurate'. We want something that's meaningful to most people, even if technically it does more than that. ... it is not Flash but is a standalone video format. Well how about Video::FLV or Video::Format::FLV then? (Or even Video::Flash::FLV?) That would be like naming a CSS parsing module HTML::CSS::Parser, Yes, and I wouldn't object to that -- especially if CSS were a much less-well-known technology, such as when CSS clearly has utility beyond just HTML, despite its dominant usage. Yeah, but dominant usage is a great way of finding something. Anybody who wants to use CSS for something else is bound to know that HTML is its dominant usage. CSS has recently been used to format a book using Yes Logic's Prince ... but HTML was still used for the mark-up. 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
* Eric Wilhelm [EMAIL PROTECTED] [2005-12-02 00:20]: What all file format parsers and dumpers have in common is that they deal with File Formats. In a lot of cases, the only module that is going to be created is for that format. I'm working on CAD::DXF for now, but would rather name it FF::DXF, similarly with FF::SVG, FF::XAR, FF::PDF, etc. I thought you were using “FF” as a shorthand for FileFormat on which I had no particular opinion, but following discussion indicates you actually proposed a literal “FF“ TLNS. In that case, I am strongly -1. It’s opaque without explaination, and even if you know what it means, you can’t meaningfully search on it. Both are terrible properties for a name. Regards, -- Aristotle “Like punning, programming is a play on words.” – Alan J. Perlis, “Epigrams in Programming”
Re: New module: FLV file parsing
* 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? Let’s just stick with
Process::video::x_flv
Process::application::x_shockwave_flash
Process::image::x_dxf
Process::audio::mpeg
Process::image::png
Process::text::html
...
please.
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Searching and Browing (was: Re: New module: FLV file parsing)
Austin Schutz wrote: On Fri, Dec 02, 2005 at 04:04:11PM -0600, Chris Dolan wrote: So, I already published it as FLV::Info, but this discussion has convinced me that FileFormat::FLV is the best option. I may use that name for v0.02. My only hesitation is that nobody else seems to be using that top-level namespace at this time. 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. Two bad assumptions here: 1) the searcher always knows what words to search for, and 2) searching is an acceptable substitute for browsing. In this case of course, 'flash' is pretty obvious and searching for it should give one everything on CPAN, but in other cases this might not be true. For example, I had a little trouble with the RSS and Atom distinction, and had I been even more ignorant, I might have missed some useful modules. Taking the other side of the coin, browsing is much more useful when the module has a name that can catch the eye. Right now we only have two 'browsing' modes in CPAN, the Recent Arrivals list, and the all-but-useless Module List Chapter. I'd like to see true browsing, arranged in a tree structure (e.g., a list of top level names that one could click on, which would bring up a list of the TopLevelName::NextLevelNames, and so on). Granted that I'm using a non-existent feature [1] to demonstrate a point, but just how useful would an FF top level name be in this situation? 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? Choosing meaningful variable names in your code is considered good programming practice. Why wouldn't it be an equally good practice for naming modules? -john [1] In theory, this means that I just volunteered to work on this. Given that, does this idea interest anyone?
Re: New module: FLV file parsing
Hi Chris,
I’ll make the assumption that whoever is going to look for the
module is most likely to simply query search.cpan.org for “FLV”.
On that basis, how descriptive are the ideas?
* Chris Dolan [EMAIL PROTECTED] [2005-11-30 16:10]:
So, is FLV::Info fine?
That sounds okay.
Or File::FLV? Or File::FLV::Parser?
I don’t think File:: is right for this.
In any case, File::FLV says nothing particular about the module.
Instead of File::FLV::Parser I’d suggest Parse::FLV. But putting
it under Parse:: means you’ll have to put modules in disparate
TLNSes if you ever write a module that supports things other than
parsing the format. If you actually plan to use the same codebase
for a family of modules that include support for manipulating as
well as parsing such files, that would be a silly choice.
Or Video::FLV?
Sounds forced to me. The module doesn’t have to do much with
video per se, other than that the file format it parses is a
container for video data. So in essence, to the searcher, the
Video:: part is redundant.
Bottom line, it’s probably best to stick it in FLV::Info and call
it a day.
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 Wednesday 30 November 2005 07:49 am: Or File::FLV? Or File::FLV::Parser? I don’t think File:: is right for this. Right, because it's not a filehandle or otherwise IO/filesystem related. Should we be using an FF:: namespace for File Formats? I've got a few modules that would like to live there too. --Eric -- Time flies like an arrow, but fruit flies like a banana. --Groucho Marx --- http://scratchcomputing.com ---
Re: New module: FLV file parsing
isn't there a multimedia name space? name spaces per-product that is being supported make sense --- Flash::parseFLV perhaps? Or File::FLV? Or File::FLV::Parser? I don't think File:: is right for this. Right, because it's not a filehandle or otherwise IO/filesystem related. -- David L Nicol Which is better, to burn out or to fade away? Refer to authorities from classical Roman, Greek and Chinese thought in your answer.
