in reply to Re: Re: How do I make one package use a module from another package?
in thread How do I make one package use a module from another package?

I may have meisunderstood your original post. If you want to use strict; use warnings, why not just do so?

Those 2 things can't be doen from a separate module to affect the calling program - their effect is lexically scoped, so it can apply, at most, to the file it is in.

Anyhow, I saw the word "pollute" and thought you were talking about a module that would import from yet other modules and then export to main:: and I can't help thnking that that way lies madness. Large function modules that break things down into smaller modules do so by inheritance, not import/export. Look at LWP::UserAgent for example, and try to find where the headers are set/interpreted, etc.

--Bob Niederman, http://bob-n.com

Replies are listed 'Best First'.
Re: Re: Re: Re: How do I make one package use a module from another package?
by Anonymous Monk on Jul 22, 2003 at 04:28 UTC
    No, I think you got what I was saying. I want to pollute. What's the best way of doing this? Why is inheritance better than import/export? Why does madness lie yonder?
[reply]

      Importing into your module means that function names that are defined nowhere in your code are suddenly significant. This is sort of OK and sometimes convenient, but only if done directly, IMO, by which I mean you use Some::Module and it exports functions into your space that you can lookup by saying perldoc Some::Module.

      But if Some::Module imports from 4 other modules, then exports to your space, it gets harder to track down what's happening, espcially if one of those 4 other modules does the same.

      Using an OO implemntation, where the module's methods are only aavailble via an object call (my $o = Some:Object->new(); my $result = $o->do_it_all_now(@parms)) means that you are far less likely to have name collision amongst the subs in your various modules because they're tracked down by the object. Then, if the modules you're calling needed to be broken down to work, they use and inherit from other modules, rather than imporutng and exporting (in general) for the same reasons.

      It's cleaner, and that gets more important when more programs - and especially when more programmers - are involved.

      There are lots of writeups that will do a much better job than I've just done of explaining this - I hope I've given some flavor of this.

      --Bob Niederman, http://bob-n.com
[reply]
[d/l]

      > I want to pollute. What's the best way of doing this?

      Typically, namespace pollution is handled via symbol table manipulations. Here's an untested import sub that pushes functions from Carp and Test into the caller's namespace with different names: 

      require Carp;
require Test;
@myexports = (
  { spkg => 'Carp', ssub => 'carp', name => 'complain' },
  { spkg => 'Test', ssub => 'ok', name => 'test_ok' },
);
sub import {
  my $callpkg = (caller)[1];
  foreach $sym ( @myexports ) {
    no strict;
    *{"$callpkg\::$name"} = \&{"$spkg\::$ssub"};
  }
}

      [download]

      Note that as discussed below, strict and warnings are pragmas and do not operate in the same way as the symbol exporting shown above.

      > Why does madness lie yonder?

      I think this has been well answered elsewhere in this thread. *grin*

[reply]
[d/l]

In Section Seekers of Perl Wisdom