Re^2: A simple import() for those special moments

[Aristotle]

Thanks for the constructive comments - that's the kind of reply I was hoping for.

All points accepted. I tried to change it with your arguments in mind and noticed an obvious, major caveat along the way I hadn't picked up on before because I still don't fully grok typeglobs: it exports the entire typeglob - lock, stock and barrel. If an importing package already has a $foo_bar, this routine will overwrite the typeglob in the process of exporting &foo_bar, even if it never exports a $foo_bar of its own.

Oops.

That was not what I had in mind. So I pulled out my Camel and read up on typeglobs, the section that talks about the *sym{THING} syntax and tried grepping the list of slots of each glob. That works fine - except the SCALAR slot always contains a reference, whether such a package wide scalar has been named or not. In other words, if *x{SCALAR} is \undef, there is no way to know whether it wasn't mentioned at all (and should therefore not be exported) or it was mentioned in such as undef $x; or use vars qw($x); which define but do not assign a value to the variable.

Which means this approach is not viable..

Makeshifts last the longest.

[ihb]

it exports the entire typeglob

I thought that was intentional. :)

If an importing package already has a $foo_bar, this routine will overwrite the typeglob in the process of exporting &foo_bar, even if it never exports a $foo_bar of its own.

It's more likely to be the other way around, i.e.

  sub foo_var { 'a' }
  use Foo;
  foo_var(); # Undefined subroutine called.

It's easy to check if a glob gets overwritten though.

This isn't such a big issue as you seem to think. Problems will only occure when you import after defining your own data types. Special exception for subroutines though. They can be declared and that (including the prototype) can disappear. E.g.

  sub foo_var ($$);
  use Foo;
  foo_var;

complains under strict because &foo_var isn't declared anymore when foo_var; is found.

Anyway, usually modules are use()d before subroutines are defined, and subroutines are usually defined before variables. So it's not that bad. This works perfectly (albeit a bit dangerous):

  use Foo;
  sub foo_var { 1 }
  foo_var();

Cheers,
ihb

[Aristotle]

Good point. Maybe a viable compromise would be to check for the existence of the target glob and croak if one is already there?

Makeshifts last the longest.

[Aristotle]

I knew there was a reason I didn't feel comfortable with it:

#!/usr/bin/perl
BEGIN {
        $SIG{__WARN__} = sub { print "Warn in package ".caller().": ",
+  @_ };
    package X;
    $foo = "I'm in X, export me!";
    *Y::foo = *foo
}

package Y;
sub foo { "Oh dear.. I wasn't meant to be outside Y" }
warn $foo;

package X;
warn foo();

__END__
Warn in package Y: I'm in X, export me! at t.pl line 11.
Warn in package X: Oh dear.. I wasn't meant to be outside Y at t.pl li
+ne 14.

In other words.. all globals exported by copying the entire typeglob will have all the packages that import them sharing all globals with the respective names - and this is more than "just" a heavy caveat.

Makeshifts last the longest.

[ihb]

This is more of a theoretical danger though. Yes, it can leak and we both know you shouldn't actually do this. It's not very safe to use a pattern to decide what to export to begin with. Stuff like this should be done explicitly, so you know what you have and what you get, etc.

But when is this leaking a problem? Sure, X gets an extra subroutine. But what difference does that make? When would X be calling this &foo, if it doesn't exist? Sure, there's the AUTOLOAD issue, but we have to believe that whoever uses the technique in the root node is knowing what he's doing and knows not to use AUTOLOAD since he implicitly aliases symbols. Symbols, I repeat.

"But what if X has its own &foo", I hear you (or someone else) say. If defined before the import, no problem. That can be detected and issue a warning. (A glob overwrite warning.) If defined after the import, well, then you get a debugging hell--if you're not using warnings. Because a "Subroutine %s redefined" warnings will be issue. If not using warnings, well, I don't want to think about it. The package will change the exporting module's &foo and that will in its turn change all &foo's out there that has been imported. (It doesn't actually do this chain. They're all just one and the same.)

To put this in context of your code in the root node: The importing module shouldn't have any symbol names what-so-ever that matches the pattern that the exporting module uses. (Of course documented in the exporting module.) Neither module should be using AUTOLOAD, since symbols are aliased implicitly. The &foo issue above can be generalized: all importing modules will share the same symbol, meaning that if one importing module modifies the symbol then all importing modules will also get the symbol modified.

This all might seem scary as hell, and yeah, it can be. But this is also a quick'n'dirty hack. Since when is "arbitrary" imports considered OK by the purists anyway?

ihb

PS. I'm not actually arguing with you, even though it may sound like it. I'm just elaborating on the subject.