Re^2: Context aware functions

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.

Comment on Re^2: Context aware functions - best practices? Download Code

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));` [download] 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];` [download] 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	[reply] [d/l] [select]
Re^4: Context aware functions - best practices? by Aristotle (Chancellor) on Jan 14, 2003 at 23:32 UTC
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.	[reply]
Re^5: Context aware functions - best practices? by LAI (Hermit) on Jan 15, 2003 at 14:33 UTC
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];` [download] 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	[reply] [d/l] [select]