sub method {
  my $self = shift;
  my $i = shift;
  my $old = $self->{B}[$i];
  $self->{B}[$i] = shift if @_;
  $old;
}
[download]

-- Randal L. Schwartz, Perl hacker

Consider this scenario. Say we have some parent object that is going to pass of some work to some number of child objects. How many child objects? Don't know; more could be added later depending on the task. Say some method in most of the children require $foo, $bar, and $baz. You could write them like:

sub my_sub {
    my $self = shift;
    my $foo  = shift;
    my $bar  = shift;

}
[download]

But, say later down the line, we want to write this new child that also needs $bork to be passed into that method. So, depending on how much stuff you have to pass around, this could quickly become a mess.

Thus I use a hashref to bypass a lot of this.

sub my_sub {
    my $self   = shift;
    my $params = shift;

    my $foo = $params->{'foo'};
    my $bar = $params->{'bar'};

}

# and in another child we could have
sub my_sub {
    my $self   = shift;
    my $params = shift;

    my $foo = $params->{'foo'};
    my $bork = $params->{'bork'};
}

# and the parent calls them like
$child->my_sub({'foo' => $foo,
                'bar' => $bar,
                'baz' => $baz,
                'bork' => $bork});
[download]

/\/\averick

If I were to do this, I'd probably do just a bit more to make it obvious:

sub method {
    my ($self, $i) = @_;
    
    if (@_ > 2) {
        $self->{B}[$i] = $_[2];
    }
    return $self->{B}[$i];
}
[download]

sub method {
  my ($self, $i, $new) = @_;
  my $old = $self->{B}[$i];
  $self->{B}[$i] = $new unless @_ < 3;
  return $old;
}
[download]

My personal view is the "if @ >=3" if preferable to the "unless" option. We are wanting to do something if there are still some paramaters to process - so write it that way. Whether the ">2" or ">=3" is better, well, that to me is personal choice. However, the ">2" option is the minimalist solution - we don't care how many paramaters there are, as long as there is at least one more.

The second issue is the one Merlyn raised - what is the most desirable to make processing decisions on subroutine paramaters? Merlyn's way - doing a shift on @_ and processing each paramater in turn is probably the safest way. Each paramater has its processing "self containted" - that is, you are not relying on its position in the @_ array, or the total number of arguments, or other potential time bombs.

sub method {
  my ($self, $i, $new) = @_;
  my $old = $self->{B}[$i];
  #make sure we have correct number of parameters
  $self->{B}[$i] = $new if @_ > 2;
  return $old;
}
[download]

sub method {
  my ($self, $i, $new) = @_;
  my $old = $self->{B}[$i];
  #make sure we have correct number of parameters
  $self->{B}[$i] = $new if @_ >= 3;
  return $old;
}
[download]

The one reason for checking the size of @_, rather than whether $_[2] is defined, is that you may actually want to allow someone to call the method with undef as an argument.

Says blogan:

> Couldn't you do an (if defined $new) also?

No. chipmunk is exactly right here; the function needs to be able to set members of the B array to undefined. In fact, an earlier version of the code did use ...if defined $new and had a terrible bug that led to an infinite loop, because items weren't being set to undef when they needed to be.

Thanks for the suggestion, though.

Well, I'd probably help my user by catching some coding mistakes rather than letting them cause strange behavior that they'd have to spend much more time debugging:

sub method {
    my $self= shift(@_);
    croak 'Usage: $oldVal= $obj->method( $idx [, $newVal ] )',$/
      unless  1 <= @_  &&  @_ <= 2;
    my $i= shift(@_);
    my $old= $self->{B}[$i];
    $self->{B}[$i]= shift(@_)   if  @_;
    return $old;
}
[download]

sub method {
    my $self= shift(@_);
    croak 'Missing $idx; usage: $oldVal= $obj->method( $idx [, $newVal
+ ] )',$/
      unless  @_;
    my $i= shift(@_);
    my $old= $self->{B}[$i];
    $self->{B}[$i]= shift(@_)   if  @_;
    croak 'Too many args; usage: $oldVal= $obj->method( $idx [, $newVa
+l ] )',$/
      if  @_;
    return $old;
}
[download]

{
    my $usage;
    BEGIN { $usage= '$oldVal= $obj->method( $idx [, $newVal ] )' }

    sub method {
        my $self= shift(@_);
        croak "Missing \$idx; usage: $usage\n"   unless  @_;
        my $i= shift(@_);
        my $old= $self->{B}[$i];
        $self->{B}[$i]= shift(@_)   if  @_;
        croak "Too many args; usage: $usage\n"   if  @_;
        return $old;
    }
}
[download]

Why, in your last suggestion, do you use a BEGIN block? Are there any circumstances where $usage would not be set if you hadn't placed the assignment to it in a BEGIN block?

I always assume that subroutines will be put into a scope where they will be compiled and never run [ that is, the subroutine will probably be called, but the lines around the subroutine will never be run ].

If you don't use the BEGIN, then you have a race condition because the subroutine exists and can be called as soon as it is compiled but its "static variable" (will be declared but) won't be initialized until that line gets run, which could happen much later or not at all.

I first ran into this problem with some border cases of using modules. The one that I remember was having two modules that depend on each other. Perl actually manages to get this mostly right (doing better than I would have thought was even possible). But the effect is that if A.pm uses B.pm which uses A.pm, then either A::import() or B::import() will be called before the code for that module gets run. I recall finding another case that was less easy to justify ignoring, but I don't remember the specifics right now.

Another case is self-inflicted. I hate having to read "between" a huge list of subroutine declarations looking for the run-time statements so I force my top-level run-time code into sub main and enforce this discipline by ending my global declarations with:

exit(  main( @ARGV )  );
[download]

(see (tye)Re: Stupid question for other self-inflicted discipline).

So I guess that boils down to "No, I don't have any glaring, screaming, obvious cases that make not doing this a really, really bad idea." (: It is a personal coding habit that has saved me time more than once. It avoids a race condition, which is usually a good thing.

        - tye (but my friends call me "Tye")

i usually prefer having a blank line between the subroutine body and the return call so that:
a) know exactly where it's returning, easy for maintenance
b) know exactly what it's returning, easy for debugging

These are just my preferences...

jynx

I heard from a wise old Perl guru once that using >= or <= rather than > or < is less efficient. I have no idea whether this is true or not, but I have no reason to doubt it. The wise guru's point was that >=/<= was in fact two operations or took longer to process than >/<.

Anyone know if this is true? I'd be very interested to find out...

-Gryphon.