Re: Resource file module (was: author ID request)
On Tue, Aug 28, 2001 at 12:49:52PM +0100, Tim Bunce wrote: I think the Mac:: category could be read as 'Macish'. Same goes for all the platform specific categories. Spawning Macish::, Win32ish::, VMSish::, Solarisish:: categories would not be good! Certainly if I wanted to read a Mac file I'd look in the Mac category. How would one determine if Win32::Registry uses the Win32 API to query the registry database or if it can read .reg files directly and reimplements registry API? There are over 100 Win32 modules on CPAN, all of them require the underlying Win32 API and will not work otherwise. Why would one assume that some of them might be useful on the other platforms (and practically useless on win32.) -- I'm going to sing Twinkle Twinkle in Jazz: TWINKle, TWINKle, lit-tle-star. HOW i WONder what-you-are... - Samantha Langmead, age 4
Resource file module (was: author ID request)
On Mon, Aug 27, 2001 at 09:59:46AM -0400, Kirrily Robert wrote: On Mon, Aug 27, 2001 at 12:21:06AM -0400, Andrew M. Langmead wrote: | 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. In that Usenet thread that I pointed to earlier, someone mentioned FileFormat:: as a possibility. I guess with that my module would be FileFormat::Mac::Resource. The counter argument to that is similar to your Data:: argument. All files have some sort of format and so it is essentially meaningless. A FileFormat:: hierarchy could argue for FileFormat::XML, FileFormat::PDF::, FileFormat::TeX, FileFormat::Text::TeX and then the FileFormat:: part is essentially meaningless. Last night when writing my previous response, I was toying with something that would imply that the it was working with uniquely macintosh data but not macintosh native. Unfortunately the best I could come up with was Macish::Resource. 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:: So we're kind of in sync on what its doing. Resource forks on macintosh's are accessed with a set of I/O routines that don't follow POSIX style stream semantics. I guess its somewhat analogous to fixed record files on VMS in that they are contained in the same file system, but need different I/O calls than a stream of bytes. (I guess another way of looking at it is if Unix had DBM built into the file system code and things like dbm_fetch() and dbm_nextkey() were system calls rather than library routines.) The reason I passed by File:: before was that most of those modules fit well withing the module lists description of File Names, File Systems and File Locking in that they either deal with a file's metadata and not its contents (File::Find, File::Glob, File::stat) or deal with their contents as a whole with indifference towards its contents (File::Copy, File::Rsync) So with those issues out, I guess names I find reasonable, in order of preference, would be: Macish::Resource FileFormat::Mac::Resource File::Mac::Resource -- I'm going to sing Twinkle Twinkle in Jazz: TWINKle, TWINKle, lit-tle-star. HOW i WONder what-you-are... - Samantha Langmead, age 4
Re: author ID request
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.comhl=ensafe=offscoring=rrnum=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?
author ID request
% your name: Andrew Langmead % your email address: [EMAIL PROTECTED]: % your homepage if you have one: % your preferred user-ID on CPAN: LANGMEAD % a short description of what you're planning to contribute: 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. -- You know, sometimes I just smile for no reason at all. - Samantha Langmead, age 4
