in reply to Using a 'package' as a 'module', and choosing at runtime?

If you know what use does (perldoc -f use, perldoc -f require) ... an example is File::Spec (a core module)
package File::Spec; use strict; use vars qw(@ISA $VERSION); $VERSION = '0.86'; my %module = (MacOS => 'Mac', MSWin32 => 'Win32', os2 => 'OS2', VMS => 'VMS', epoc => 'Epoc', NetWare => 'Win32', # Yes, File::Spec::Win32 works on Ne +tWare. dos => 'OS2', # Yes, File::Spec::OS2 works on DJGP +P. cygwin => 'Cygwin'); my $module = $module{$^O} || 'Unix'; require "File/Spec/$module.pm"; @ISA = ("File::Spec::$module"); 1; __END__
Sure you don't need to actually require/use anything, but @ISA is @ISA ;)(perldoc perlmod, perldoc perlvar ...)

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
** The third rule of perl club is a statement of fact: pod is sexy.

Replies are listed 'Best First'.
Re: Re: Using a 'package' as a 'module', and choosing at runtime?
by pg (Canon) on Oct 28, 2003 at 11:20 UTC

    require is definitely a good and straight answer to the question, and I believe this must be one of the original reasons made them to have require in Perl in the first place. As sometime, you simply either cannot determine what to use at compile time, or you cannot determine whether you even require anything.

    The other way seems also very natual is to have a base class and those platform-specific classes subclass it. Less efficient, but chance is that there are common attributes across platforms, and could be a pretty neat design.

    Actually should be a mixture of both, a neat OO design with dynamically loading of subclasses.