On , Nikita Popov wrote:
On Wed, Jun 10, 2015 at 8:53 AM, Stanislav Malyshev
<smalys...@gmail.com>
wrote:
Hi!
> <?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.
Why it's wrong? You try to get that's something not there, you get
NULL.
I don't see anything wrong. Adding fatal error about every little
thing
that isn't as expected never was how PHP worked.
I agree with what other people have said here: We should keep the
behavior
for NULL, but drop the nonsense for other types - (42)[24] not throwing
a
notice is quite ridiculous, that seems like a pretty obvious bug to me.
Nikita
PHP raises a notice when attempting to access properties on null. Surely
it should be consistent and also raise a notice for array access on
null? Array access on null is still a potential bug in the developers
code.
In addition to trying to avoid breaking existing code, I chose a notice
for my PR ( https://github.com/php/php-src/pull/1269 ) because it's
consistent with the behaviour of property access on non-objects, and
also allows developers who wish to use a looser style to simply disable
notices.
I personally don't believe raising an error or EngineException in this
case would fit with the way people expect PHP to work (in addition to
causing an unnecessary BC break). If an EngineException is introduced
for this, I believe a notice / deprecation must be issued first (even if
current behaviour is undefined) to allow developers time and adequate
notification to change their code.
To answer an earlier query, my PR does raise multiple notices for
deep-access (as in the last example given above). This is consistent
with the behaviour on deep-property access on scalars/null.
AllenJB
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
