in reply to Re: Module Announcement: Perl-Critic-1.01
in thread Module Announcement: Perl-Critic-1.01

Well, whenever being explicit breaks things. return; and return undef; is NOT the same thing! It does return the same thing in a scalar context, but a very different thing in a list one. So for example 

sub foo {
 return undef;
}

if (@results = foo()) {
  print "Helo jettero :-P\n";
}

[download]
does print the greeting. Because the function returns a list containing one element, the undef. And once you assign the list to an array and evaluate that assignment in scalar context you get the number of elements in the list and thus a true value. Probably not what you wanted, right?

Jenda
Support Denmark!
Defend the free world!

Replies are listed 'Best First'.
Re^3: Module Announcement: Perl-Critic-1.01
by Rhandom (Curate) on Jan 26, 2007 at 19:32 UTC
    You are correct. I can't argue that that is what happens when you return undef.

    Now - the larger question is, who is still designing Perl module interfaces that return non-scalar results.

    I can't remember the last time I designed a function to return a list of values - much less variably return a list or a single scalar depending upon context. To me it is a code smell to not return a single scalar value (the single value could be arrayref or hashref - but it is still a single value). I know that may not sound Perlish - but as a user of the modules I produce I prefer not have to guess what context I need to call items in. It also saves memory to return arrayrefs or hashrefs.

    Yes I still use map and grep and caller and times and stat, but they are some of the last things I use that return lists. Perl 6 will fix some of these issues.

    my @a=qw(random brilliant braindead); print $a[rand(@a)];
[reply]

      So I guess you'd rather do 

      my $pointless_reference = $obj->getPosition();
my ($x, $y) = @$pointless_reference[0,1];

      [download]
      or 
      my ($x, $y) = @{$obj->getPosition()};

      [download]
      instead of 
      my ($x, $y) = $obj->getPosition();

      [download]
      right? Restricting myself to returning just one value just because most languages do not allow anything more seems silly to me. Especially compared to such dirty tricks as updating the values of some variables passed by reference or something.

      To me bending backwards to always return a single scalar is a code smell. A code smell sugesting that the author writes C or some other language, but definitely not Perl. Even though the code is full of sigils and there are regexps scattered around.

      Jenda
      Support Denmark!
      Defend the free world!

[reply]
[d/l]
[select]
        Absolutely!

        I think that the following is perfectly fine. 
        my ($x, $y) = @{ $obj->getPosition }

        [download]
        Depending upon the interface I think that it may be better to return a point reference or object rather than the xy coordinates themselves. 
        my $point = $obj->getPosition;
do_something_with_point($point);
printf "X is %.2f\n", $point->x;
# or maybe $point->[0] - possibly bad
# or maybe $point->{x} - probably bad
# but really $point->x is the best

        [download]

        It is funny that you should use a geometry example. Many of the C or C++ libraries that I have seen that deal with graphics primitives prefer to pass around a point struct rather than the individual x or y.

        Just because it is possible to make interchanged data as terse as possible doesn't mean it is the right thing to do.

        my @a=qw(random brilliant braindead); print $a[rand(@a)];
[reply]
[d/l]
[select]

In Section Meditations