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