Re: An alternate way of implementing import with options

grep() won't do anything bad to @_, but I am personally against doing two operations in a row like you did that are complements.

That being said, I'd rewrite the @_-filtering line as:

my %args;
push @{ $args{ref($_) eq 'HASH' ? 'opt' : 'ext'} }, $_
  for @_;
[download]

Or, I might even do a moving-splice() trick:

sub import {
  my $self = shift;
  my ($i,$j,@options);

  for (@_) {
    if (++$j, ref($_) eq 'HASH') {
      push @options, splice(@_, $j + --$i, 1);
      $_ = $_[$j+$i], redo if $j + $i < @_;
    }
  }

  # handle @options
  # @_ now only holds elements which aren't hash refs

  $self->SUPER::import(@_);
}
[download]

</code>

japhy -- Perl and Regex Hacker

Comment on Re: An alternate way of implementing import with options Select or Download Code

Replies are listed 'Best First'.
Re (tilly) 2: An alternate way of implementing import with options by tilly (Archbishop) on Feb 13, 2001 at 21:43 UTC
That fails. The point of the goto in the original is that Exporter checks caller to figure out what package to export symbols to. You have to use export_to_level() instead, and my experience suggests that that function is more likely to cause warning messages to come from the wrong place than I like. (Also with 5.6+ it will force you to load Exporter::Heavy which is slower. If that matters to you.) Aside from that, I don't like using explicit indexes if I can avoid it...	[reply]
Re: Re (tilly) 2: An alternate way of implementing import with options by japhy (Canon) on Feb 13, 2001 at 21:46 UTC
Oh, d'oh, right. I knew there was some reason I knew `goto` was being used. So yeah, modify my code as needed. Silly jeffy. `japhy` -- Perl and Regex Hacker	[reply]