http://www.perlmonks.org?node_id=226927


in reply to Re: Context aware functions - best practices?
in thread Context aware functions - best practices?

You are aware that scalar (@x = foo(1,2,3,5)); will evaluate to the number of elements returned by foo rather than return the last one of them, right? :) And no, I even considered returning an array ref. (But not a concatenation, yuck - if the caller wants unstructured data he can flatten the array himself, but he can't well unflatten a string.) I'm not going to ask this particular function for two return values when I'm only interested in one of them though. I just don't want to have to remember and to type the parens in every instance I only ask for one return value, because that will be pretty a common case. CGI::param works the same way with good reason, f.ex.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re^3: Context aware functions - best practices?
by LAI (Hermit) on Jan 14, 2003 at 21:50 UTC
    You are aware that
    scalar (@x = foo(1,2,3,5));
    will evaluate to the number of elements returned by foo rather than return the last one of them, right? :)

    Yes, of course. I wrote that in reference to my $x = foo(1); setting $x to 1 :oP

    I agree that it would be a rare case when the flattened array would be an acceptable return value, but I still don't like the idea of throwing away data. Oh, well. The only alternative I can think of is the hideous

    return wantarray ? @arr : $#arr ? \@arr : $arr[0];

    which borders on the obfuscated. I wouldn't use something like that if I were you. Of course I'm me, and love using lines like that, but I digress...

    Zaxo's suggestion of using $arr[-1] makes sense too, especially if the sub is doing something cumulative with its args. Imagine a sum() function that keeps track of all the intermediate sums, or whatever.


    LAI
    :eof

      Ugh, that's the worst of both worlds, esp if I didn't know the number of return values beforehand (I do in the situation at hand). In that case every invocation in scalar context will have to be tested with ref.. if it at least consistently returned an arrayref I wouldn't have to think about it.

      As I said, what I want is the same convenience as CGI offers with my $foo = $cgi->param(''); vs my ($foo) = $cgi->param(''); - you get the same result either way. Nothing else.

      If you don't like the idea of throwing away results, consider my $foo = (bar(), baz(), qux());. I'm asking for pretty much the same semantics.

      Makeshifts last the longest.

        Ugh, that's the worst of both worlds

        Hurrah for nauseatingly ugly code...

        Anyway, yeah. The return type would definitely have to be the same regardless of the args. Having to test the type every time a sub is called is unacceptable. How does CGI's $calar = $cgi->param() decide which value to return, though (if it's a multivalue parameter)? Is it just the first (or last) one input?

        I just RTFM'd and RTFSource'd, and CGI->param() does this:

        return unless defined($name) && $self->{$name}; return wantarray ? @{$self->{$name}} : $self->{$name}->[0];

        There you have it, I guess. Return the whole array or the first element. I still like Zaxo's idea of returning @rray[-1], though... I guess it depends what sub foo does.


        LAI
        :eof