in reply to Re: to much hybries
in thread to much hubris

I try to keep it simple, as possible - so I hope the performance is well, but it will not work in each case thatswhy. But it has some features I can easy realize with this code. A real live example would be a modul which has for each HTML Tag from Tagset a subroutine. There are to much possible combinations to build a tag for each. Exporting all makes things slower if it is imported from many places. Ensure somewhere is the namespace "from" loaded.
package A; import from 'HTML::TAGS::AsFunctions' => 'Div A Img';
Another usecase is to export subroutines.
package B; sub import{ export from _ => qw/foo bar/ }
And the third, it enables you to relay subroutines.
package SubRelay; sub import{ export from FooModule => 'foo'; export from BarPackage => 'bar'; }

Replies are listed 'Best First'.
Re^3: to much hybries
by ysth (Canon) on Feb 09, 2007 at 00:38 UTC
    So, it seems to me you have two different uses; one is a normal function import, only with no @EXPORT_OK, etc. restrictions on what symbols are allowed, to save having to have an explicit list. This sounds like a not-so-hot idea, for a number of reasons.

    The other is a nicer interface for what Exporter's export_to_level does; I'm not sure this is worth writing a separate module for.

      The first point I can not share, because this module does no black magic. Perl allows such things so a restriction like @EXPORT_OK is more or less only a hint for the programmer and is a easy way to export things. But I'm looking for a solution which makes import easy.

      If the use of this package becomes modern, the use of modules like Attribute::Protected will increase or something similar, I don't know.