Chris, Sorry for not responding.
On 2002.01.11, at 08:37, Chris Nandor wrote: >> Anyway, since then my policy to upload a module is as follow; >> >> 0) Make sure it does not exist yet. >> 1) Upload and see what happens. > > Well, I am a member of the [EMAIL PROTECTED] cabal; the general practice > is that if something is OK, we don't necessarily respond. If no one > responds after a week or so, you're probably fine. But that doesn't > mean you shouldn't ask first. I don't necessarily think that your name > is wrong, but I do think you should post to [EMAIL PROTECTED] first for > such things as new top-level namespaces. Maybe Mac::X would be better, > I dunno. That's why it is discussed first. :) Okay, I will. I heareby request namespace MacOSX for the use by modules that are platform-specific to MacOS X. As for the replies (or lack there of) from [EMAIL PROTECTED], 0 reply for OK is pretty much like Unix commands. But for administrative this is terribly wrong. Simple autorespond like that of CPAN would be welcome. As for the namespace Mac::X, I object because this is confusing with X window. > 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. 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, 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. > 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 :) Dan the Man with Too Many Namespaces to Browse
