in reply to DWIM: autoloading classes

Paranoid as I am, I am wondering whether the automatic loading of Foo::* modules isn't opening some serious security holes, because you can never know whether someone hasn't put a "Foo::Takeovereverything" module somewhere in @INC (especially with "." usually being part of @INC). Of course, this could be considered a feature as well.

Personally, I like the following idiom better for object oriented modules, as it makes it easier to use a lot of modules _and_ still keep a better overview:

use Foo qw(Bar Baz);
which would be equivalent to:
use Foo (); use Foo::Bar (); use Foo::Baz ();

Foo::import would look something like this:

my @module = qw(Bar Baz); # allowable modules my %module = map {$_ => 1} @module; # easy lookup of modules sub import { my $class = shift; return if $class ne 'Foo'; # allow import to be inherited by submo +dules my @require; # list of modules to be required if (@_) { foreach (@_) { if ($_ eq ':all') { @require = @module; } elsif ($module{$_}) { push @require,$_; } else { warn "Don't know how to load Foo::$_\n"; } } } else { @require = @module; } foreach (@require) { next if eval "require Foo::$_;"; # string eval for easiness warn "Foo::$_: $@"; # could be die also if you prefer } } #import

With apologies to those for whom this would be bleedingly obvious.

Liz

Replies are listed 'Best First'.
Re: Re: DWIM: autoloading classes
by tsee (Curate) on Sep 17, 2003 at 23:26 UTC
    While I'm too tired to implement it, one should be able to add import functionality to the above code so that symbols exported by Foo::Bar via "use Foo 'Bar';" are exported to the calling namespace. That should be doable by testing whether Foo::Bar uses Exporter to handle import() and friends and use the export_to_level() routine from Exporter. If the module uses its own import routine, one might... well... do evil things with eval and package.
      Not that I want to export anything: I do everything OO and nothing gets exported in my modules. If there are any global flags that would need to be set, I use class method accessors for them.

      But anyway, but I fail to see what more evil things you could do with an exporter that you couldn't already do.

      So what ev(i|a)l things exactly are you referring to?

      Liz

        Stuff like string eval of changing to the calling package and invoking the import routine from there. Then go back to the (main module) package you were using to load the other modules.
        I don't know whether that's already enough to fool caller().

        Steffen