On Wed, Mar 25, 2009 at 10:50:44AM -0500, David Nicol wrote: > I'm for Class::ForSystem or Class::ForOS, with the magically included > per-OS packages being > under the proposed module, such as Class::ForOS::linux::File::Tail > which is what Class::ForOS would load the replacements out of, were > Class::ForOS used in File::Tail where $^O eq 'linux'. Ah; I was thinking that the per-OS specialisations of a module would live within that module's namespace; similar to how File::Spec works.
> Class::PerOS is also appealing instead of Class::ForOS. (see other thread for further thoughts on names). > How does it interact with AUTOLOAD? Does it matter if it is used at > the top or bottom of the module, or in the middle? I hadn't given any thought to AUTOLOAD so far - what issues do you foresee here? > Is there a > possibility of other systems of alternatives that key on something > other than $^O (such as the ever-popular "use less ..." family of > imaginary modules, for declaring optimization priorities, which now > appears on CPAN, as documentation only) playing nice with > Class::PerOS, by providing hooks? Hmm; again I don't quite see how you're intending this. Perhaps a little example? > Class::Alternatives could be a framework for frameworks of providing > alternatives, of which Class::PerOS would be the first demonstration I sometimes prefer to work backwards, in fact. Starting with a need (per-OS subclases), provide an interface to allow people to solve that problem. Implementation doesn't matter too much - as long as the interface is right, we can fix the implementation later. Having made Class::PerOS, if there are other distinctions that might require Class::Alternatives, then Class::PerOS can be changed to use that instead without anybody really noticing or caring. Easier too, to start from an existing real problem and work backwards towards its more generic solution. -- Paul "LeoNerd" Evans leon...@leonerd.org.uk | CPAN ID: PEVANS
signature.asc
Description: Digital signature
