On 06/12/2014 03:03, Yasuo Ohgaki wrote:
Hi Rowan,
On Fri, Dec 5, 2014 at 6:12 PM, Rowan Collins <rowan.coll...@gmail.com
<mailto:rowan.coll...@gmail.com>> wrote:
The author of function f1() presumably designed it to apply some
change to $v, rather than executing only for its side effects and
return value. If the caller wants to ignore this design, they can,
but they are not using the function as it was designed. If they
pass a function return straight into it, they have no way of
capturing the change to $v which the author intended them to see.
The value supplied to f1() is return value.
In languages, there are literal, constant and variable. Return value
is variable.
No, a return value is a value - it is the result of some computation
which has not yet been assigned to a variable. This is perhaps more
obvious with an operator: "1 + 2" is not a variable, it is the value 3;
internally, a temporary variable is probably used to hold that value,
but that temporary variable is never accessible to the programmer. If
you have function add($a, $b) { return $a + $b; }, then add(1,2) is
still not a variable in any meaningful sense.
It's better to keep basic rule. IMHO.
$top = array_pop(f2());
is better than
$v = f2();
$top = array_pop($v);
Is there anyone who likes latter?
array_pop() is a stack-manipulation function, so the latter is the
correct use, with $v going on to be used as the rest of the stack. If
you're using it for something other than stack manipulation, neither is
correct, because it's the wrong choice of function.
Are there any other languages behave like PHP?
In some languages - e.g. Pascal, Transact-SQL - the most common form of
sub-routine is a "procedure", which doesn't return a value in the way
that a function does, but instead has "input" and "output" parameters.
Supplying something other than a variable to an "output" parameter would
clearly be just as wrong as putting it on the left-hand side of an
assignment (e.g. f2() = f1()).
Even in languages with functions or methods rather than procedures as
their main building block, it's common to have output-only parameters to
capture multiple return values without the need for a complex return
type. For instance, it might be legal to pass the return value of
malloc() in C straight to something requiring a pointer to some memory,
but it's almost certainly a mistake to do so, because you would have no
way of accessing the buffer afterwards.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
