Hi all,
----- Original Message -----
From: "Christoph Becker"
Sent: Tuesday, June 09, 2015
Yasuo Ohgaki wrote:
I fully agree that current behavior could be used meaningful ways.
However,
<?php
$foo = 42;
$foo['bar']; // => NULL
$v = NULL;
$v[0][1][2][3][4][5][6][7][8][9]; // NULL
this code is semantically wrong and I would like to have error/exception
for such
erroneous codes. It's inconsistent with array object, too.
Raising exception/error is correct behavior for types that aren't array.
To avoid errors, users should use isset()/is_array()/etc.
I agree that the code is not clean, and that an isset check is
appropriate, particularly as one could do:
$v = NULL;
$v[0][1][2][3][4][5][6][7][8][9] ?? NULL; // NULL
Forgetting the NULL case for a sec... With:
$v = [];
$v[0][1][2][3][4][5][6][7][8][9];
How/why are we going from 1 Notice to 10?!
With:
unset($v);
$v[0];
Why from 1 Notice about the undefined variable, to 2? That's totally new,
and it really doesn't make sense to make any more noise after you've already
been told about the variable. (Same after the first undefined array offset,
too, but this makes the point more obvious.)
That's why I'm saying, you can only really change it for non-NULL scalars
that have an actual value, to keep this other stuff the same, and sane.
I don't really see a semantic issue with the NULL case, either, unlike other
scalar types.
Since we have debate for this PR, this PR would be good for RFC targeting
PHP 7.1.
It seems to me that raising an exception or throwing an error (instead
of a notice) could be too much of a BC break for a minor version.
Just wondering, in the exception case, does that mean 10 exceptions also
(one for each dimension)...?
--
Christoph M. Becker
- Matt
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
