Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106932
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <CEC35EF9-9956-44BE-8C8E-EE5FC3D5A7C7@gmail.com>
Date: Thu, 12 Sep 2019 15:17:36 +0700
Cc: Nikita Popov <nikita.ppv@gmail.com>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <D5DDA318-E953-4AB8-873F-7CA7264722E2@koalephant.com>
References: <CAF+90c9Kc6m_bv=aJxbD3-RmnNXXLqv6mPjHp7U7qxX_ck27qw@mail.gmail.com>
 <CAF+90c_KHYm1SLOKkZXM6xurYiDTX3=hbijpD8rT1OSUHSod_w@mail.gmail.com>
 <CEC35EF9-9956-44BE-8C8E-EE5FC3D5A7C7@gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings
From: php-lists@koalephant.com (Stephen Reay)


> On 12 Sep 2019, at 14:40, Claude Pache <claude.pache@gmail.com> wrote:
>=20
>> Le 10 sept. 2019 =C3=A0 15:31, Nikita Popov <nikita.ppv@gmail.com> a =
=C3=A9crit :
>>=20
>> On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov <nikita.ppv@gmail.com> =
wrote:
>>=20
>>> Hi internals,
>>>=20
>>> 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.
>>>=20
>>> I've prepared an RFC with some suggested classifications, though =
there's
>>> room for bikeshedding here...
>>>=20
>>> https://wiki.php.net/rfc/engine_warnings
>>>=20
>>> Regards,
>>> Nikita
>>>=20
>>=20
>> Heads up: This RFC may go to vote tomorrow.
>>=20
>> Nikita
>=20
>=20
> I have objections to those two reclassifications:
>=20
> * Undefined offset: %d =E2=80=94 Notice =E2=86=92 Warning
> * Undefined index: %d =E2=80=94 Notice =E2=86=92 Warning
>=20
>=20
> =46rom 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.
>=20
> 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 =E2=80=9Cin principle=E2=80=9D, because a perfectly =
reasonable coding style may choose to enforce initialisation of =
variables, but not of array keys.
>=20
> 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.
>=20
> declare(
>    uninitialized_variables: error
>    uninitilalized_index: none
> );
>=20
> 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.
>=20
> 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.
>=20
> =E2=80=94Claude
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20


I=E2=80=99ve 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=E2=80=99t exist, and of course there is often =
a proposal to have a declare statement or something similar, to allow =
their =E2=80=9Ccode style=E2=80=9D 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=3D1);


This would suppress any errors about undefined variables, array offsets, =
would reverse the =E2=80=9Cbare 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?=20



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=E2=80=99s =
some herculean task to either define variables/offsets first; or check =
if they=E2=80=99re defined; or use an appropriate method to access them =
that specifically allows for undefined variables/offsets (i.e. the ?? =
and ??=3D operators)