At 17:40 +0900 2002.01.14, Dan Kogai wrote: > Okay, I will. I heareby request namespace > >MacOSX > > for the use by modules that are platform-specific to MacOS X.
.... > As for the namespace Mac::X, I object because this is confusing with X >window. Yes, I agree it is confusing. I am not crazy about MacOSX, but can think of nothing better, so I am not objecting. >> My problem is that I think this module should have the same interface as >> Mac::Files and should be called Mac::Files and then programmers on both >> platforms can "use Mac::Files" and just have it work. > > Mine does not have the same interface. That's why I picked the >different name space to begin with. After XS (therefore C compiler) is >imperative for make install MacOSX::File (though binary distribution is >considered when it gets stable) something you can't expect of MacOS 9 >and below. What can be expected of Mac OS (9) isn't relevant, since binary distributions are possible (and the norm). We have binary distributions of all the Mac modules, plus many other modules; certainly a binary distribution of this module for Mac OS 9 would be possible, if it were written to be compatible (or were patched as such). So it makes me wonder again if MacOSX is the right place for it, if indeed it can work on both platforms. > Oh, that reminds me. Is there a canonical way to upload BINARY >version of the module? I can make it so that Makefile.PL works like an >installer rather than Makefile generator but is it the way? Well, there is a canonical way on Mac OS, but I don't know about Mac OS X. You can grab one of the distributions from my user directory (CNANDOR) and examine it; essentially, I put the binary files in their place (macbinarizing them), and then there is special code in ExtUtils::Mac / CPAN / Mac::BuildTools to handle them. It wouldn't be as complex for Mac OS X to handle it, if for no other reason but that you wouldn't need MacBinary for anything. >> Well, OK, maybe not. But I do want *A* module called "Mac::Files" on >> Mac OS X that has the same interface as Mac::Files on Mac OS, though, >> and what I don't want is for there to be confusion in the long run as to >> what these modules should and shouldn't do ... > > It would be nice, too but that requires more than my share of work. >Resorting to reinventing a wheel is a pain enough. But the issue is that there *will be* Mac::Files on Mac OS X eventually. So with your module, there will be two sets of modules that do the same thing, one of which is incompatible with Mac OS (perhaps). This isn't necessarily a bad thing, but I would like to see something like this module just be a stopgap measure until the full toolbox set is available via the Mac:: modules, because I would rather people use modules compatible for both OSes when possible, for maximum portability. >> What I really should do is just port the Mac:: modules, but I don't have >> the time to do that work. :/ > > Yes, that's always the problem. As for MacOSX::File, I was too lazy >to use Finder to backup a hundred of thousand of files (vanilla MacOS X >with Developer Kit well exceeds 100,000 files). I was too impatient to >wait for someone come of a module like this. And I was too hubristic to >wait for the verdict of [EMAIL PROTECTED] > What other virtues do I need :) I am not denying the need for the module, and I am not saying the module as it exists is wrong in any way. But the issue of duplicated functionality and compatability (as well as the issues of what File::Copy etc. should do) need to be addressed, so that we all know what direction things are headed, and so that interested parties have a chance to weigh in. Thanks, -- Chris Nandor [EMAIL PROTECTED] http://pudge.net/ Open Source Development Network [EMAIL PROTECTED] http://osdn.com/
