On Mon, Aug 27, 2001 at 12:21:06AM -0400, Andrew M. Langmead wrote:
|
| 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?
Those two examples aren't analogous.
I'm expect to find platform-independent tools for identifying Windows
file types or for manipulating the Windows registry under Win32::,
however. I'd expect to find popen under POSIX::.
| 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>
I just asked on #perl and the response was unanimously "Mac", and
unanimously against "Data". One mac-knowledgeable person there asked
what resource-fork model your module worked with, and suggested
Mac::Resources::Netatalk or Mac::Resources::LinuxHFS or similar.
| 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?
A suggestion was made for starting a top-level namespace for
cross-platform tools, but no good name was suggested for it.
The general process you should be doing is drilling down on this blurry
"data" thing and saying "what sort of data is it?" Well, it's a file.
OK, so how about File::? Perhaps something like File::Mac::Resources?
Or if it's more like a file system (I'm not very knowledgeable about
macs) then perhaps Filesys::
But *not* Data.
K.
