Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106934
MIME-Version: 1.0
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>
In-Reply-To: <CEC35EF9-9956-44BE-8C8E-EE5FC3D5A7C7@gmail.com>
Date: Thu, 12 Sep 2019 11:27:22 +0200
Message-ID: <CAF+90c8OBnnBbHKnp2XbDA2cXf--z-cqW+73hwJTFBX5L3N5SQ@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b1abf2059257bfb8"
Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000b1abf2059257bfb8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 12, 2019 at 9:40 AM Claude Pache <claude.pache@gmail.com> wrote=
:

> > Le 10 sept. 2019 =C3=A0 15:31, Nikita Popov <nikita.ppv@gmail.com> a =
=C3=A9crit :
> >
> > On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov <nikita.ppv@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 generatin=
g
> 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 =E2=80=94 Notice =E2=86=92 Warning
> * Undefined index: %d =E2=80=94 Notice =E2=86=92 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 =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, i=
n
> 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
>

Hi Claude,

I have split off the question of undefined array keys into a separate
section, which will be voted separately.

I generally agree that ignoring undefined array key notices can be a
legitimate coding style choice (while I would very much disagree that the
same is true for undefined variables) -- though ultimately I think it is
best to handle this with a custom error handler (which can check whether
the error originated from your own codebase), rather than through a blanket
suppression of notices. In line with that thinking I don't think it matters
overly much whether it's a notice or warning for the purposes of
suppression. But I also don't feel particularly strongly about having this
case as a warning either, especially with the error_reporting=3DE_ALL defau=
lt
in PHP 8.

Nikita

--000000000000b1abf2059257bfb8--