> Le 10 sept. 2019 à 15:31, Nikita Popov <nikita....@gmail.com> a écrit :
>
> On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov <nikita....@gmail.com> wrote:
>
>> Hi internals,
>>
>> I think it's time to take a look at our existing warnings & notices in the
>> engine, and think about whether their current classification is still
>> appropriate. Error conditions like "undefined variable" only generating a
>> notice is really quite mind-boggling.
>>
>> I've prepared an RFC with some suggested classifications, though there's
>> room for bikeshedding here...
>>
>> https://wiki.php.net/rfc/engine_warnings
>>
>> Regards,
>> Nikita
>>
>
> Heads up: This RFC may go to vote tomorrow.
>
> Nikita
I have objections to those two reclassifications:
* Undefined offset: %d — Notice → Warning
* Undefined index: %d — Notice → Warning
From experience, having to dutifully initialise each and every key in an array
is burdensome. I understand the rationale of enforcing that in some coding
standard; but whether those particular missing index should be considered as
unexpected (therefore deserving a Warning) is mostly a question of coding style.
This is in principle a similar issue as using uninitialised variables, which,
as noted in this thread, is a perfectly accepted coding pattern in some
languages (the issue being distinct from *undeclared* variables). I say “in
principle”, because a perfectly reasonable coding style may choose to enforce
initialisation of variables, but not of array keys.
PHP has the advantage of supporting various coding styles. We should give the
opportunity to the users to say declaratively (and precisely) what, in their
coding style, is considered as acceptable, e.g.
declare(
uninitialized_variables: error
uninitilalized_index: none
);
of course, possibly at a package-level declare. That would, for example, enable
people to place legacy code in lax mode and chose a stricter mode for new code,
even letting the precise notion of strictness vary with fashion without having
to review working code written two years ago.
That said, as long as those issues are handled as errors (as in:
set_error_handler()) rather than exceptions, one may write a proper error
handler that does the distinction (I do that). However, an error handler has
the disadvantage of being global, making difficult the integration of code
written with differing coding standards.
—Claude
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
