Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106931
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <CAF+90c_KHYm1SLOKkZXM6xurYiDTX3=hbijpD8rT1OSUHSod_w@mail.gmail.com>
Date: Thu, 12 Sep 2019 09:40:06 +0200
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <CEC35EF9-9956-44BE-8C8E-EE5FC3D5A7C7@gmail.com>
References: <CAF+90c9Kc6m_bv=aJxbD3-RmnNXXLqv6mPjHp7U7qxX_ck27qw@mail.gmail.com>
 <CAF+90c_KHYm1SLOKkZXM6xurYiDTX3=hbijpD8rT1OSUHSod_w@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings
From: claude.pache@gmail.com (Claude Pache)

> 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


I have objections to those two reclassifications:

* Undefined offset: %d =E2=80=94 Notice =E2=86=92 Warning
* Undefined index: %d =E2=80=94 Notice =E2=86=92 Warning


=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.

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.

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.

=E2=80=94Claude