in reply to to much hubris

Some documentation of its features would help alot. It would also be nice to see whats this modules advantages and disadvantages as compared to Exporter.


___________
Eric Hodges

Replies are listed 'Best First'.
Re^2: to much hybries
by pmSwim (Acolyte) on Feb 08, 2007 at 18:54 UTC
    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'; }
      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.