|There's more than one way to do things|
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.
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.
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):
In reply to Re: Re^2: A simple import() for those special moments