Besides flagging that wantarray could be useful here
It's not. You don't pick an assignment operator then design the function it's operand will call. You design the function first, then you write the code that will assign the return value or the part of the return value that's desired (whether it uses wantarray or not).
# f() returns three elements
my $first = f(); # XXX, unless f() also allows this
my ($first) = f(); # OK, uses list assignment
my $first = ( f() )[0]; # OK, extracts desired scalar first
my (undef, $second) = f(); # OK, uses list assignment
my $second = ( f() )[1]; # OK, extracts desired scalar first
# g() returns a variable number of elements
my $last = g(); # XXX, unless g() also allows this
my $last = ( g() )[-1]; # OK, extracts desired scalar first
my $count = @all = g(); # OK, list assignment in scalar cx
my $count = () = g(); # OK, list assignment in scalar cx
Like I already said, deciding what to have a sub return is a lengthy topic entirely unrelated to the behaviour of the assignment operators.
| [reply] [Watch: Dir/Any] [d/l] [select] |
Further: approaching the question of "what is the difference between list and scalar context, and when are they applied?" via an experiential/experimental approach with wantarray is eminently practical. To wit, here's a simple test script I wrote when I wanted to clarify the matter for myself. This most definitely constitutes Another Way To Do It:
#!/usr/bin/perl -w
sub polymorphic {
my $context=wantarray();
if ($context) {
print "list context\n";
return @_;
} elsif (defined($context)) {
print "scalar context\n";
return join ":", @_;
} else {
warn "value of polymorphic() used in void context. Values were (\n
+";
# so no point in returning anything, but do print
print join ",", @_;
print ")\n";
}
}
sub show_args {
print "got ", scalar(@_), " args:\n";
map {print " $_\n" } @_;
}
show_args("a", polymorphic("b","c","d"));
my $string=polymorphic(1,2,3);
my @array=polymorphic(4,5,6);
show_args($string,@array);
# make warning 1
polymorphic("unused");
# following is tricky because we don't know context until tricky is
# actually called.
sub tricky {
polymorphic(@_);
}
my $string2=tricky(qw(a b c d));
my @array2=tricky(qw(s t u v));
show_args($string2,@array2);
# make warning 2
tricky(qw(fee fi fo fum));
# what happens if we use return keyword explicitly?
sub tricky_2 {
return polymorphic(@_);
}
my $string3=tricky_2(qw(a e i o u));
my @array3=tricky_2(qw(w x y z));
show_args($string3,@array3);
# (turns out we can use return or not; same result--no warning)
# (but this should generate one)
tricky_2(5,6,7,8);
sub tricky_3 {
my $first=shift;
my $second=shift;
my @remaining=@_;
print "$first, $second, (";
print join ",", @remaining;
print ")\n";
};
| [reply] [Watch: Dir/Any] [d/l] |
It's not
Question: what is the point in writing a tutorial explaining the difference between list and scalar contexts?
Answer: so that people who don't know the difference can gain some enlightenment.
Question: Besides poring over man pages or searching the Internet, what other way is there to gain an understanding of when a list context is implied and when a scalar context is implied
Answer: write a sub that calls wantarray and divine the context directly
Have I made my point?
| [reply] [Watch: Dir/Any] |
huh?
Are you saying I wrote a tutorial on contexts? I didn't, but someone else did over here.
Are you saying you're writing a tutorial on contexts? All the power to you, but maybe should start a new thread (where people will actually see it) instead of placing it in a reply to some unrelated post.
| [reply] [Watch: Dir/Any] |