On Tue, Mar 24, 2009 at 3:30 AM, Paul LeoNerd Evans <leon...@leonerd.org.uk>wrote:
> I find a number of times, that I've wanted to make some code that > certain OSes would have better implementations of than others, or just > plain implement in a different way. > I'm not really liking any of the names that have been proposed so I'm going back to the original message to give my thoughts. The "English" name of $^O is $OSNAME, so there's precedent for OS. I think it should use OS and not something like System. As for where to put it, the way this would be useful to me would not be as any sort of object (which rules out Class::) but as a sort of assertion or query about the operating system. You wouldn't need to instantiate any objects of this class, it would just be for asking "what OS am I running on?" so OO is really not needed except maybe for some @ISA magic. I think File::Spec has the right architecture for this but the author(s) made some (IMHO) poor choices in determining the class hierarchy, such as filing Win32 under Unix. But we're not here to redesign File::Spec. However, how about package names like OS::linux, OS::Win32, etc.? OS.pm itself could accept some export() arguments, to set assertions. use OS has_symlinks; # would fail under Windows use OS::linux; # would fail under any non-Linux OS When you load OS.pm it would set itself up according to $^O to load the appropriate subclass, and then you can make inquiries to methods using the OS namespace and it would delegate the same way File::Spec does. What specific OS-related questions do you want this for? Obviously not filesystem naming rules...
