(about terms and language)
My lack of understanding of the English language is showing. I was confusing 'jargon' and 'terms'.
Well, it seems to confuse you at any rate. But that doesn't make it wrong.
Indeed, my confusion does not make it wrong. Its inaccuracy does.
As others have already pointed out, some very well known people including the Camel triumvirate have used this phrasing.
And as I have replied, BrowserUk quoted obsolete documentation and stuff that hasn't got anything to do with what we're talking about. See my answer to his list of fake sources here.
Your arguments are not convincing.
That much is obvious. But this is your error, not mine.
| [reply] |
How about a middle ground? Document that the subroutine's return acts like an array on the RHS. Yay.
| [reply] |
Document that the subroutine's return acts like an array on the RHS.
You have to be specific even then. It doesn't act like an array on the RHS of the push operator, or the RHS of the chomp operator, or the RHS of a (\@) prototype sub, or the RHS of the \ operator.
"Acts the way an array does at the RHS of the assignment operator" versus "Returns a list of foos in list context, the number of foos in scalar context". Tough choice :)
| [reply]
[d/l]
[select] |
sub foo {
my @array = (1,5,9);
return @array;
}
But some have argued that not only is it technically incorrect to say
'returns an array', but that it is confusing and misleading. It is
perfectly reasonable and understandable to document what the return
expression of a routine is; and the behavior of that expression (and thus
the resulting return value) is perfectly inferrable: size of the array
in scalar context, and the contents of the array in list context. Why
should I continually re-document this basic Perl rule whenever my
return expression is an array, when simply saying 'returns an array' says
it all? People might enjoy quibbling about it, but they aren't the least
bit confused by it.
| [reply]
[d/l] |
