Re: Namespace [Was: Re: MacOSX::File]
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Brian McNett) wrote: > On Monday, January 14, 2002, at 09:42 AM, Chris Nandor wrote: > > > I wonder if maybe we should have Carbon:: or Cocoa:: namespaces? Even > > Mac::Carbon:: or Mac::Cocoa:: or Mac::Aqua:: etc. This would be > > Mac::Carbon::Something in that case ... > > I haven't weighed in on this issue (or much of anything of late) > but this would seem to be the most reasonable solution. This > would give us Mac:: as the "classic" MacOS namespace, > Mac::Carbon:: as the transitional API (with CarbonLib on MacOS 9 > and earlier systems), and Mac::Cocoa as the namespace for MacOS > X (and later) modules. Although I would still push for similar > interfaces across similar modules (and there will be some > duplicate functionality regardless of what else happens). Note that the "Classic" Mac toolbox *is* almost entirely Carbon, however. There's been some thought that the port of the Mac:: toolbox to Carbon could be in Mac::Carbon::, with the same interface, though I am not sure it's necessary. At this point, I figure the Mac:: toolbox modules should stay where they are, in lieu of companions in Mac::Carbon::, although additional Carbon modules could go there. Or something. I dunno, I am still trying to figure it out myself. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Namespace [Was: Re: MacOSX::File]
On Tuesday, January 15, 2002, at 04:05 AM, Chris Devers wrote: > On Mon, 14 Jan 2002, John Gruber wrote: > >> Chris Nandor <[EMAIL PROTECTED]> wrote on 1/14/02 at 9:27a: >> >>> Yes, I agree it is confusing. I am not crazy about MacOSX, >>> but can think of nothing better, so I am not objecting. >> >> I have a feeling that "MacOSX" is not future-proofed. > > That's true, but it might work in the same way that "Win32" does. There, > of course, is no Windows 32 product, but rather a family of them that > can > be described as Win32. Mac OS X is clearly a big break with what > preceded > it, and presumably Mac OS XI (or whatever it will be) will evolve from > what we have now, rather than be another fundamental break. For lack > of a > better generic name for this new family of Mac systems, MacOSX might > have > to do -- though I'd be interested in better suggestions. Aqua? Darwin? My opinion is irrelevant my I sort of lean to darwin (after all that is what the hints file is called) but that may cause a problem with darwin/x11 vs darwin/aqua? Jon
Re: Namespace [Was: Re: MacOSX::File]
On Monday, January 14, 2002, at 09:42 AM, Chris Nandor wrote: > I wonder if maybe we should have Carbon:: or Cocoa:: namespaces? Even > Mac::Carbon:: or Mac::Cocoa:: or Mac::Aqua:: etc. This would be > Mac::Carbon::Something in that case ... I haven't weighed in on this issue (or much of anything of late) but this would seem to be the most reasonable solution. This would give us Mac:: as the "classic" MacOS namespace, Mac::Carbon:: as the transitional API (with CarbonLib on MacOS 9 and earlier systems), and Mac::Cocoa as the namespace for MacOS X (and later) modules. Although I would still push for similar interfaces across similar modules (and there will be some duplicate functionality regardless of what else happens). --B
Re: Namespace [Was: Re: MacOSX::File]
At 02:18 +0900 2002.01.15, Dan Kogai wrote: > FYI Here is the reason why I picked MacOSX:: RELUCTANTLY. Mac:: >should work on both world but mine does not. But taking a quick glance at it, there is no reason why it couldn't work on Mac OS (Classic), aside from the fact that you've not designed it to *build* on Mac OS (Classic). Am I missing something? >Aqua:: is the Name of UI >so it should belong to modules that does things like Tk:: or Qt::. I wonder if maybe we should have Carbon:: or Cocoa:: namespaces? Even Mac::Carbon:: or Mac::Cocoa:: or Mac::Aqua:: etc. This would be Mac::Carbon::Something in that case ... -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Namespace [Was: Re: MacOSX::File]
On 2002.01.15, at 02:05, Chris Devers wrote: >>> Yes, I agree it is confusing. I am not crazy about MacOSX, >>> but can think of nothing better, so I am not objecting. >> >> I have a feeling that "MacOSX" is not future-proofed. > > That's true, but it might work in the same way that "Win32" does. There, > of course, is no Windows 32 product, but rather a family of them that > can > be described as Win32. Mac OS X is clearly a big break with what > preceded > it, and presumably Mac OS XI (or whatever it will be) will evolve from > what we have now, rather than be another fundamental break. For lack > of a > better generic name for this new family of Mac systems, MacOSX might > have > to do -- though I'd be interested in better suggestions. Aqua? Darwin? FYI Here is the reason why I picked MacOSX:: RELUCTANTLY. Mac:: should work on both world but mine does not. Aqua:: is the Name of UI so it should belong to modules that does things like Tk:: or Qt::. The biggest contender was Darwin:: but BSD world of MacOS X is the prime example that's wrong. If Darwin:: were appropriate, native /bin/ commands would have treated resource fork like MacOS. Oh well Dan the Man with Too Many Acronyms to Grok
Re: Namespace [Was: Re: MacOSX::File]
At 11:44 -0500 2002.01.14, John Gruber wrote: >Chris Nandor <[EMAIL PROTECTED]> wrote on 1/14/02 at 9:27a: > >> Yes, I agree it is confusing. I am not crazy about MacOSX, but can think >> of nothing better, so I am not objecting. > >I have a feeling that "MacOSX" is not future-proofed. > >What happens if the next major revision to the OS is _not_ named >"Mac OS X 11", but instead "Mac OS XI", or (preferably) "Mac OS 11"? Yeah, another good point. Hrm. Although, the way Apple is doing it now, the OS is named "Mac OS X" and its version is "10.1.2", so the complete name is "Mac OS X 10.1.2"; similarly, it is "Mac OS 9.2.1". So if they continued with that, it would be "Mac OS X 11.0". However, there is no way of knowing what Apple will do in this regard; I don't think consistency is necessarily going to be the standard by which future rules apply. I wonder if maybe Mac:: is a better namespace, and then say in the docs which versions of "Mac" are supported? -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Namespace [Was: Re: MacOSX::File]
On Mon, 14 Jan 2002, John Gruber wrote: > Chris Nandor <[EMAIL PROTECTED]> wrote on 1/14/02 at 9:27a: > > > Yes, I agree it is confusing. I am not crazy about MacOSX, > > but can think of nothing better, so I am not objecting. > > I have a feeling that "MacOSX" is not future-proofed. That's true, but it might work in the same way that "Win32" does. There, of course, is no Windows 32 product, but rather a family of them that can be described as Win32. Mac OS X is clearly a big break with what preceded it, and presumably Mac OS XI (or whatever it will be) will evolve from what we have now, rather than be another fundamental break. For lack of a better generic name for this new family of Mac systems, MacOSX might have to do -- though I'd be interested in better suggestions. Aqua? Darwin? -- Chris Devers [EMAIL PROTECTED] Apache / mod_perl / http://homepage.mac.com/chdevers/resume/
Re: Namespace [Was: Re: MacOSX::File]
Chris Nandor <[EMAIL PROTECTED]> wrote on 1/14/02 at 9:27a: > Yes, I agree it is confusing. I am not crazy about MacOSX, but can think > of nothing better, so I am not objecting. I have a feeling that "MacOSX" is not future-proofed. What happens if the next major revision to the OS is _not_ named "Mac OS X 11", but instead "Mac OS XI", or (preferably) "Mac OS 11"? -- John Gruber [EMAIL PROTECTED]
Re: Namespace [Was: Re: MacOSX::File]
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/
Re: Namespace [Was: Re: MacOSX::File]
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
Re: Namespace [Was: Re: MacOSX::File]
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Dan Kogai) 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. :) > So far so good. But of course, I am open to opinions. If enough number > of you (well, even I am not sure how many would be enough. Say if my > mailbox gets flooded with complaints) don't like it I am happy to change > that. > As for the toplevel 'MacOSX', I first considered 'Darwin' but Dawin's own > /bin/cp and /bin/mv ignore Resource fork. Then I considered 'Carbon' but > What actually my module does is to bridge both worlds. So I picked MacOSX, > the name that contains both worlds. 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. 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 ... What I really should do is just port the Mac:: modules, but I don't have the time to do that work. :/ -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Namespace [Was: Re: MacOSX::File]
Hi Chris. Long time no see. on 02.1.9 7:46 AM, Chris Nandor at [EMAIL PROTECTED] wrote: > Hi Dan. Two comments: Okay let me answer one by one. > 1. Did you ask [EMAIL PROTECTED] about the namespace? I am not sure > MacOSX is a good top-level namespace. Maybe I should have and I did think over this issue. But I can tell you what happened when I did ask for a namespace to [EMAIL PROTECTED] before. Back then when there was no 5.6 (and not even 5.005) I made a module called Jcode, which allows you to handle varios Japanese charset (en|de)coding. The name came from jcode.pl, a (very, very) popular package that existed before Perl5. Since this 'taints' top-level module namespace I did RFC in [EMAIL PROTECTED] and I got no response for a long time. Since that namespace was empty I did upload it and now Jcode is one of the most widely-used perl module in Japan (it's now a part of FreeBSD ports and many Linux packages). When it comes this far even I cannot change the situation. 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. So far so good. But of course, I am open to opinions. If enough number of you (well, even I am not sure how many would be enough. Say if my mailbox gets flooded with complaints) don't like it I am happy to change that. As for the toplevel 'MacOSX', I first considered 'Darwin' but Dawin's own /bin/cp and /bin/mv ignore Resource fork. Then I considered 'Carbon' but What actually my module does is to bridge both worlds. So I picked MacOSX, the name that contains both worlds. Dan the PM Writer
