Bug #64755 [Com]: Only variables should be passed by reference
Edit report at https://bugs.php.net/bug.php?id=64755edit=1
ID: 64755
Comment by: a at b dot c dot de
Reported by:eth at ethaniel dot com
Summary:Only variables should be passed by reference
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Debian 7.0
PHP Version:5.4.14
Block user comment: N
Private report: N
New Comment:
For guy's example. Yes, your assumption is wrong; the suggestion 'that the type
of $value = array() is expression and not a variable' is correct. It's not a
variable, it's an assignment expression.
Previous Comments:
[2013-09-12 01:41:42] guy at syntheticwebapps dot com
To respond to eth: I'm not disagreeing with you, but just keep in mind that
before 5.4, func()[$index] was not legal syntax, so it made a lot of sense to
use phrasing like array_shift(array_splice(...)). So there's a bunch of code
out
there that uses the old approach, and in 5.4+ it's no longer considered OK.
I'm just asking: Why should it not be OK? This example around arrays is not the
only one, so the syntax you suggested will not apply to all cases. It seems
unduly inflexible to disallow values to be passed in where reference aliasing
is
intended. So what if the caller intends to disregard the response? Why force
them to care enough to create a variable of their own when that only serves
to
delay the freeing of that value from memory by one level of the call stack?
Fact
is, functions have side effects and return values and other call-by-reference
parameters which may be what the caller is really looking for. The caller
shouldn't need to pretend to care about every value they pass to a function
which deems it reference aliasable.
I realize here I'm going deeper into PHP history. I just think it's an
improvement along positive lines to relax this and not move toward strictness
for non-utilitarian reasons. Today's E_STRICT becomes tomorrow's E_DEPRECATED
and next week's E_ERROR. So why be picky about this when there's no ambiguity?
[2013-09-11 23:28:13] ni...@php.net
array_shift(array_splice($dbents, $x, 1)) does not throw an ERROR exception
(whatever that is). It throws an E_STRICT level error, which is the lowest
error type we have.
The E_STRICT tells you that you have some code that currently works, but is
discouraged. What you were actually looking for is array_splice($dbents, $x,
1)[0] (at least I assume so, because I don't really get your code sample.)
[2013-09-11 23:13:24] guy at syntheticwebapps dot com
Even worse, the following no longer works in PHP 5.4+ and this is an ERROR
exception:
$dbentry = array_shift(array_splice($dbents, $x, 1)))
This is why some leeway is appropriate on this error. I you can't chain
together
such logical progressions without INVENTING a variable in the code which has no
other purpose than to avoid this ERROR exception, the language is headed the
wrong direction and causing limitations for no cause.
I really think this needs to be fixed.
[2013-09-11 22:59:26] guy at syntheticwebapps dot com
I have a different example than the one given. Consider:
function myfunc( $refvar ) {
...
}
$horse = myfunc( $value = array() );
The code example above also gets the same exception, however, this does not
seem
correct. This suggests that the type of $value = array() is expression and
not
a variable. But this violates an assumption in the language. Is this assumption
incorrect? Should it be incorrect?
As in the original reported form of the problem, I believe there should be some
forgiveness in the call-by-reference receiver. I can understand why NOT to do
that, but there are safe ways to do it anyway, like create a new zval for local
use.
But it's more important to me that $value = array() evaluates to the VARIABLE
$value and NOT an expression. What expression could it possibly represent? The
supposed expression in such a case is meaningless, whereas the variable is
meaningful and useful. Any chance this could be fixed in future?
[2013-05-02 08:25:11] paj...@php.net
See www.php.net/array_pop.
Using: array_pop(array_keys($a)); array_keys($a) is an expression while
array_pop
expects a variable. ($k = array_keys($a);...).
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=64755
--
Edit this bug report at
Bug #64755 [Com]: Only variables should be passed by reference
Edit report at https://bugs.php.net/bug.php?id=64755edit=1
ID: 64755
Comment by: guy at syntheticwebapps dot com
Reported by:eth at ethaniel dot com
Summary:Only variables should be passed by reference
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Debian 7.0
PHP Version:5.4.14
Block user comment: N
Private report: N
New Comment:
I have a different example than the one given. Consider:
function myfunc( $refvar ) {
...
}
$horse = myfunc( $value = array() );
The code example above also gets the same exception, however, this does not
seem
correct. This suggests that the type of $value = array() is expression and
not
a variable. But this violates an assumption in the language. Is this assumption
incorrect? Should it be incorrect?
As in the original reported form of the problem, I believe there should be some
forgiveness in the call-by-reference receiver. I can understand why NOT to do
that, but there are safe ways to do it anyway, like create a new zval for local
use.
But it's more important to me that $value = array() evaluates to the VARIABLE
$value and NOT an expression. What expression could it possibly represent? The
supposed expression in such a case is meaningless, whereas the variable is
meaningful and useful. Any chance this could be fixed in future?
Previous Comments:
[2013-05-02 08:25:11] paj...@php.net
See www.php.net/array_pop.
Using: array_pop(array_keys($a)); array_keys($a) is an expression while
array_pop
expects a variable. ($k = array_keys($a);...).
[2013-05-02 08:03:55] eth at ethaniel dot com
Description:
I get a PHP Strict Standards: Only variables should be passed by reference
in
error where there should be none.
Test script:
---
echo array_pop(array_keys(array(erwre)));
Expected result:
Result: 0.
Actual result:
--
The script returns the result (0), but also a PHP Strict Standards: Only
variables should be passed by reference in in my error log.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64755edit=1
Bug #64755 [Com]: Only variables should be passed by reference
Edit report at https://bugs.php.net/bug.php?id=64755edit=1
ID: 64755
Comment by: guy at syntheticwebapps dot com
Reported by:eth at ethaniel dot com
Summary:Only variables should be passed by reference
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Debian 7.0
PHP Version:5.4.14
Block user comment: N
Private report: N
New Comment:
Even worse, the following no longer works in PHP 5.4+ and this is an ERROR
exception:
$dbentry = array_shift(array_splice($dbents, $x, 1)))
This is why some leeway is appropriate on this error. I you can't chain
together
such logical progressions without INVENTING a variable in the code which has no
other purpose than to avoid this ERROR exception, the language is headed the
wrong direction and causing limitations for no cause.
I really think this needs to be fixed.
Previous Comments:
[2013-09-11 22:59:26] guy at syntheticwebapps dot com
I have a different example than the one given. Consider:
function myfunc( $refvar ) {
...
}
$horse = myfunc( $value = array() );
The code example above also gets the same exception, however, this does not
seem
correct. This suggests that the type of $value = array() is expression and
not
a variable. But this violates an assumption in the language. Is this assumption
incorrect? Should it be incorrect?
As in the original reported form of the problem, I believe there should be some
forgiveness in the call-by-reference receiver. I can understand why NOT to do
that, but there are safe ways to do it anyway, like create a new zval for local
use.
But it's more important to me that $value = array() evaluates to the VARIABLE
$value and NOT an expression. What expression could it possibly represent? The
supposed expression in such a case is meaningless, whereas the variable is
meaningful and useful. Any chance this could be fixed in future?
[2013-05-02 08:25:11] paj...@php.net
See www.php.net/array_pop.
Using: array_pop(array_keys($a)); array_keys($a) is an expression while
array_pop
expects a variable. ($k = array_keys($a);...).
[2013-05-02 08:03:55] eth at ethaniel dot com
Description:
I get a PHP Strict Standards: Only variables should be passed by reference
in
error where there should be none.
Test script:
---
echo array_pop(array_keys(array(erwre)));
Expected result:
Result: 0.
Actual result:
--
The script returns the result (0), but also a PHP Strict Standards: Only
variables should be passed by reference in in my error log.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64755edit=1
Bug #64755 [Com]: Only variables should be passed by reference
Edit report at https://bugs.php.net/bug.php?id=64755edit=1
ID: 64755
Comment by: guy at syntheticwebapps dot com
Reported by:eth at ethaniel dot com
Summary:Only variables should be passed by reference
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Debian 7.0
PHP Version:5.4.14
Block user comment: N
Private report: N
New Comment:
To respond to eth: I'm not disagreeing with you, but just keep in mind that
before 5.4, func()[$index] was not legal syntax, so it made a lot of sense to
use phrasing like array_shift(array_splice(...)). So there's a bunch of code
out
there that uses the old approach, and in 5.4+ it's no longer considered OK.
I'm just asking: Why should it not be OK? This example around arrays is not the
only one, so the syntax you suggested will not apply to all cases. It seems
unduly inflexible to disallow values to be passed in where reference aliasing
is
intended. So what if the caller intends to disregard the response? Why force
them to care enough to create a variable of their own when that only serves
to
delay the freeing of that value from memory by one level of the call stack?
Fact
is, functions have side effects and return values and other call-by-reference
parameters which may be what the caller is really looking for. The caller
shouldn't need to pretend to care about every value they pass to a function
which deems it reference aliasable.
I realize here I'm going deeper into PHP history. I just think it's an
improvement along positive lines to relax this and not move toward strictness
for non-utilitarian reasons. Today's E_STRICT becomes tomorrow's E_DEPRECATED
and next week's E_ERROR. So why be picky about this when there's no ambiguity?
Previous Comments:
[2013-09-11 23:28:13] ni...@php.net
array_shift(array_splice($dbents, $x, 1)) does not throw an ERROR exception
(whatever that is). It throws an E_STRICT level error, which is the lowest
error type we have.
The E_STRICT tells you that you have some code that currently works, but is
discouraged. What you were actually looking for is array_splice($dbents, $x,
1)[0] (at least I assume so, because I don't really get your code sample.)
[2013-09-11 23:13:24] guy at syntheticwebapps dot com
Even worse, the following no longer works in PHP 5.4+ and this is an ERROR
exception:
$dbentry = array_shift(array_splice($dbents, $x, 1)))
This is why some leeway is appropriate on this error. I you can't chain
together
such logical progressions without INVENTING a variable in the code which has no
other purpose than to avoid this ERROR exception, the language is headed the
wrong direction and causing limitations for no cause.
I really think this needs to be fixed.
[2013-09-11 22:59:26] guy at syntheticwebapps dot com
I have a different example than the one given. Consider:
function myfunc( $refvar ) {
...
}
$horse = myfunc( $value = array() );
The code example above also gets the same exception, however, this does not
seem
correct. This suggests that the type of $value = array() is expression and
not
a variable. But this violates an assumption in the language. Is this assumption
incorrect? Should it be incorrect?
As in the original reported form of the problem, I believe there should be some
forgiveness in the call-by-reference receiver. I can understand why NOT to do
that, but there are safe ways to do it anyway, like create a new zval for local
use.
But it's more important to me that $value = array() evaluates to the VARIABLE
$value and NOT an expression. What expression could it possibly represent? The
supposed expression in such a case is meaningless, whereas the variable is
meaningful and useful. Any chance this could be fixed in future?
[2013-05-02 08:25:11] paj...@php.net
See www.php.net/array_pop.
Using: array_pop(array_keys($a)); array_keys($a) is an expression while
array_pop
expects a variable. ($k = array_keys($a);...).
[2013-05-02 08:03:55] eth at ethaniel dot com
Description:
I get a PHP Strict Standards: Only variables should be passed by reference
in
error where there should be none.
Test script:
---
echo array_pop(array_keys(array(erwre)));
Expected result:
Result: 0.
Actual result:
--
The script returns the result (0), but also a PHP Strict Standards: Only
variables should be passed by reference in in my error log.
--
Edit this
