Decide to throw the question away and name the thing Package Subs. Looks intuitive too and now it fits the recommended practices. <cite> Is the name well chosen? I wrote this lightweight Exporter alternative and want to start this tiny thing on CPAN. But it is maybe critizised to much there or it's not worth to stay there. So it is safer to ask here before. </cite> 
 1        package Package::Subroutine
 2     ; our $VERSION = '0.06'
 3     
 4     ; sub export
 5         { my $ns = (caller(1))[0]
 6         ; shift() # rm package
 7         # working shortcut for __PACKAGE__
 8         ; splice(@_,0,1,"".caller) if $_[0] eq '_'
 9         ; _import_export($ns,@_)
 10         }
 11     
 12     ; sub import
 13         { my $ns = (caller(0))[0]
 14         ; shift() # rm package
 15         ; _import_export($ns,@_)
 16         }
 17     
 18     ; sub _import_export
 19         { my $namespace = shift
 20         ; my $from      = shift
 21         ; my @methods   =  @_
 22     
 23         ; for ( @methods )
 24             { my $target = "${namespace}::${_}"
 25             ; my $source = "${from}::${_}"
 26             ; *$target = \&$source
 27             }
 28         }
 29
 30     ; sub version
 31         { my ($f,$pkg,$num)=@_  
 32         ; if( defined($num) )
 33             { $num=eval { UNIVERSAL::VERSION($pkg,$num) }
 34             ; return $@ ? undef : $num
 35             }
 36         ; eval { UNIVERSAL::VERSION($pkg) }
 37         }
 38
 39     ; sub install
 40         { my ($pkg,$target,$name,$coderef)=@_
 41         ; $target="${target}::${name}"
 42         ; *$target = $coderef
 43         }
 44
 45     ; 1
 46     
 47     __END__

[download]
Some hints applied, so the examples using a string are broken. :) Thank you all to finding this out. :)

Replies are listed 'Best First'.
Re: to much hybries
by ysth (Canon) on Feb 08, 2007 at 00:18 UTC
    @{[caller(1)]}[0] is better written (caller(1))[0].

    And perlsub says:

    Subroutines whose names are in all upper case are reserved to the Perl core, as are modules whose names are in all lower case.

    Update: I don't see any reason for a supposed light-weight Exporter replacement to support use Foo "bar baz"; as an alternate form of use Foo qw/bar baz/;. It's cute, and easy to code, but not worth introducing an API difference for. What if Foo.pm switches back from your exporter to the standard one, or somebody else's replacement; then users of Foo who took advantage of the 2-character savings are broken.

    Update 2: You really ought to check for invalid identifiers. And as a bonus, you could make leading digits trigger a $from->VERSION($_) version check, ala Exporter.

    I'm looking for a job.

[reply]
[d/l]
[select]
      It is not a replacement for Exporter and could not be. If I would publish a normal perl module I would use Exporter. The plan is, to introduce it as an alternative, which has to be well chosen. So a difference in the API is not so problematic. The Version check is a good idea. Thank you for your reply.
      Sorry, for the typo in the headline. This is what I mean: 
      i	hubris	 	die Anmaßung
i	hubris	 	die Hybris
      Writing a good and reliable perl module is more work than I thought, but it makes fun.
[reply]
        Now you've confused me; if it's not a lightweight alternative to Exporter, what is it? Who would you envision using it, and why?

        I'm looking for a job.

[reply]
Re: to much hybries
by eric256 (Parson) on Feb 07, 2007 at 23:53 UTC

    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
[reply]
      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';

      [download]
      Another usecase is to export subroutines. 
      package B;

sub import{
   export from _ => qw/foo bar/
}

      [download]
      And the third, it enables you to relay subroutines. 
      
package SubRelay;

sub import{
   export from FooModule => 'foo';
   export from BarPackage => 'bar';
}

      [download]
[reply]
[d/l]
[select]
        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.

        I'm looking for a job.

[reply]
Re: to much hubris
by dragonchild (Archbishop) on Feb 09, 2007 at 01:30 UTC
    Sub::Exporter does everything you want and more, is extremely lightweight, and maintained by one of the finest Perl minds I've ever met. I suggest you spend the time you'd spend adding features to yours learning his instead. Then, if you really want something to do, ask - I can point you at 100 projects on CPAN that could use someone with a bit of extra time.
    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

Back to Meditations