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
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
# 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
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
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
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
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
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:
Sorry, that should have been
$ perl -MModuleNumber::22 -le 'print 1'
Can't locate ModuleNumber/22.pm in @INC
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
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
* 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
* 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
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
14 matches
Mail list logo
