On Sun, Aug 26, 2001 at 07:27:24PM -0400, Kirrily Robert wrote:
> >The first thing I want to contribute is a cleaned up version of
> >Data::MacResFile, a module for non-Macintosh systems to read
> >compontents out of a Macintosh resource file.
>
> Data:: is so generic it's almost meaningless... almost everything a Perl
> module could deal with is data, and it wouldn't make sense to put every
> perl module under Data. So let's save Data for stuff that's really
> generic data manipulation and which don't obviously fit elsewhere.
>
> I'd suggest putting your module under the Mac:: namespace. Although
> Mac:: is mostly modules that run on Mac, there is at least one other
> example of a platform-independent module in there
> (Mac::FileSpec::Unixish). The real issue, though, is where would people
> look for a Mac-related module? I'm thinking they'd look in Mac::
I'm sorry, if I realize that I'd wind up defending the name, I'd have
put the rational in my original message. The OS specific name spaces
nearly universally run under the OS they are named for. Under the
Macintosh, one would be best served by using the OS's native API (as
accessed in perl with the Mac::Resource module) and not this perl
level re-implementation. As a comparison, would you expect to find a
Unix implementation of COM in Win32::OLE? A windows version of popen()
in Unix::PipedFileHandle?
The example that you gave, "Mac::FileSpec::Unixish" although it can
run on any platform is explicitly designed for running under
MacOS. the docs claim that the two exported functions nativize and
unixify are nearly no-ops under other OS's. A better example might be
Mac::MacBinary, but doing this much work to find a module in the dozen
OS specific hierarchies that doesn't run under that OS nearly proves
the rule.
When initially developing this module, I asked around for suggestions
on both the name of the module and the design (although the only
evidence I can find is this thread in comp.lang.perl.modules which the
only common answer for a hierarchy is Mac::
<URL:http://groups.google.com/groups?q=group:comp.lang.perl.modules+
author:aml%40world.std.com&hl=en&safe=off&scoring=r&rnum=9&
selm=F25vyu.IB5%40world.std.com>
Yes, Data:: describes a lot of what computer programs do, but there
are more specific hierarchies for more specific forms of processing
than just data manipulation. The Net:: hierarchy is mostly handling
the actual wire protocol. Some file formats have their own top level
hierarchy, such as XBase, Spreadsheet::Lotus, FrameMaker:: and
SystemC::. Some text formats are in the Text:: hierarchy, with similar
situations with graphics and Image:: and sound in Audio:: Resource
files, don't quite fit into one of those since one resource record can
be not only text, graphics, audio, or any sort of arbitrary data. So
yes, it is pretty vague, but what a resource fork contains is pretty
arbitrary. A resource record is a chuck of data in any arbtrary
format.
For additional consideration, despite notice in
comp.lang.perl.announce, Perl News, and The Perl Journal, no one else
has ever brought up any objections to the name.
I guess to bring it to a point, I strongly feel that Mac:: is the
wrong hierarchy for the module to be in. The choice of Data:: wasn't
done without any thought or consultation, although I agree it isn't
ideal.
Do you have any suggestions besides Mac:: for a namespace?
