> On 12 Sep 2019, at 14:40, Claude Pache <claude.pa...@gmail.com> wrote:
>
>> 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
>
I’ve seen a number of people that have concerns about PHP throwing actual
errors (as opposed to notices) because they try to use a variable/offset that
doesn’t exist, and of course there is often a proposal to have a declare
statement or something similar, to allow their “code style” to run without
errors.
So, my proposal to the situation is to introduce a single declare that solves
that problem, once and for all.
declare(sloppy=1);
This would suppress any errors about undefined variables, array offsets, would
reverse the “bare words" change when encountering an undefined constant, etc.
Heck, for good measure this mode could even re-implement register_globals and
magic_quotes, because why not?
If you want to write sloppy code, that is entirely your prerogative, but please
just own it for what it is, and stop pretending that it’s some herculean task
to either define variables/offsets first; or check if they’re defined; or use
an appropriate method to access them that specifically allows for undefined
variables/offsets (i.e. the ?? and ??= operators)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
