Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

what do u think about this way to fast import subroutines? 
sub import { *{caller().qq'::$_'} =\&$_ for qw'sub1 sub2' }

[download]
i know i can _use_ exporter...

and... do u know how to write it to run under strict?

Replies are listed 'Best First'.
Re: fast import?
by broquaint (Abbot) on Sep 28, 2003 at 14:34 UTC
    That's a fine way to export subs if you simply want subs from the current package to be exported to the calling package, and while it may be much faster than the likes of Exporter, speed isn't really an issue when it comes to importing.

    While you could get this working under strict, it would mean going through many hoops to avoid symbolic referencing, so this is one of those cases where turning off strictures is a good idea 

    ## limit the disabling of strict refs to this scope
{
  ## let us do symbolic referencing
  no strict 'refs'

  sub import {
    ## get the caller once
    my $pkg = caller;

    for(qw/ sub1 sub2 /) {
      ## don't over-write existing subs
      *{"$pkg\::$_"} = \&$_
        unless defined &{"$pkg\::$_"};
    }
  }
}

    [download]
    The only reason I can think for using Exporter apart from laziness, is it can export symbols to a higher calling frame, otherwise I reckon Juerd's Exporter::Tidy is pretty ideal (although it could do with optional exporting, time for a patch methinks ...)1.

    HTH

    _________
    broquaint

    1 just realised this doesn't make any sense. move along folks

[reply]
[d/l]
Re: fast import?
by bart (Canon) on Sep 28, 2003 at 14:35 UTC
    what do u think about this way to fast import subroutines?
    I don't mind. In fact you're doing what Exporter does. I'm not convinced it'll be much faster, though. And it's less flexible: you always export these subs.

    and... do u know how to write it to run under strict?
    Temporariliy disable strict. 
    no strict 'refs';

    [download]
    strict is designed to prevent this kinds of tricks, so you can't have both at the same time.

    You can put it inside the sub, limiting its effect to the block it's in.

[reply]
[d/l]
Re: fast import?
by PodMaster (Abbot) on Sep 28, 2003 at 14:31 UTC
    do u know how to write it to run under strict?
    Yes, the question here is why don't you? And I can answer it, it's because you don't know what strict does. I suggest a brief `perldoc strict' reading session(no strict).

    update: Or, if that's not clear enough for you, you can try Tutorials -> Use strict and warnings

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]
      lol podmaster, did u read my post or only the strict word?
[reply]
[d/l]
      A reply falls below the community's threshold of quality. You may see it by logging in.
Re: fast import?
by petdance (Parson) on Sep 28, 2003 at 19:08 UTC
    Why do you care how fast it is? What code are you trying to optimize?

    (And if you're not actually trying to optimize some code, then why do you care how fast it's going?)

    xoxo,
    Andy

[reply]
Re: fast import?
by tilly (Archbishop) on Sep 30, 2003 at 00:53 UTC
    I think that you are not giving the person using your module any flexibility about what subroutines they are accepting from you, and you are guaranteeing that some maintainance programmer later will be staring at some code and have no (easy) way of tracking down where sub1 and sub2 are defined, let alone what they do.

    If you are developing any significant amount of code, both of these limitations are bad enough to keep me from wanting to use your module.

    In short, Exporter doesn't offer its flexibility for the heck of it. It offers flexibility because that flexibility when used appropriately is useful for improving developer efficiency. If you don't like trading off runtime performance for developer efficiency, then Perl is probably the wrong language for you. You would be happier with something like C or C++ that allow you to get far better performance at the cost of more up front work.

    Also if you are concerned with startup time because, for instance, you are trying to speed up a web page, then you would be far, far better off to eliminate it entirely through something like mod_perl.

[reply]

Back to Seekers of Perl Wisdom