Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106936
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> <D5DDA318-E953-4AB8-873F-7CA7264722E2@koalephant.com>
 <E30D9A22-9842-4A67-ABA5-A339875FFE12@gmail.com>
In-Reply-To: <E30D9A22-9842-4A67-ABA5-A339875FFE12@gmail.com>
Date: Thu, 12 Sep 2019 12:32:14 +0200
Message-ID: <CAG9XoMTG3OLbD0BfWv+ORUUsbMV2CaF0Ea4NLF1huHBr5JCmWQ@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: Stephen Reay <php-lists@koalephant.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000061b43a059258a78f"
Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings
From: benjamin.morel@gmail.com (Benjamin Morel)

--00000000000061b43a059258a78f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> For example when I=E2=80=99m writing a throw-away script, some notices ar=
e okay to
> indicate possible problems


Maybe it's just me, but even in throw-away scripts, *I've lost much more
time because of warnings/notices going unnoticed, than I've saved thanks to
PHP's forgiving nature*.
Hence even in the shittiest of my scripts, I usually end up registering an
error handler to throw an exception even for the smallest notice. At least,
I always get an exception right in my face when something's unexpected, so
I can fix it and move on, and avoid surprises later on.

Sure, in a quick script, I do see some value in being able to write stuff
like:

    @ $array['non_existing_key']++;

It's still sloppy though: what you're really doing is muting a notice and
incrementing null.
Instead, I feel like there should be a stronger support from the language
to specifically handle this kind of use cases, rather than using them as a
justification for not *severely *hardening error reporting.
I don't think there are that many such *potentially *legitimate use cases,
so maybe we could just list the use cases and think about a more elegant
solution to solve them?

In other words, if that was only me, the whole notice/warning stuff would
go, and PHP would only have exceptions.
Undefined variables would throw, undefined array keys would throw, and use
cases like the above would have stronger language support to avoid
boilerplate code full of if(isset()).

=E2=80=94 Benjamin

On Thu, 12 Sep 2019 at 11:42, Claude Pache <claude.pache@gmail.com> wrote:

>
>
> > Le 12 sept. 2019 =C3=A0 10:17, Stephen Reay <php-lists@koalephant.com> =
a
> =C3=A9crit :
> >
> >
> >
> > I=E2=80=99ve seen a number of people that have concerns about PHP throw=
ing
> 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 undefi=
ned
> 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, bu=
t
> 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)
> >
> >
>
> Declare(sloppy=3Dyeah) is not granular enough. To all: please, do underst=
and
> that everything is not black or white; this remark is not directed
> specifically to that particular issue, this is an attitude I see regularl=
y
> on that mailing list.
>
> There is no such thing as =E2=80=9Cone true strict coding standard=E2=80=
=9D and =E2=80=9Cone
> legacy lax coding standard=E2=80=9D. For instance:
>
> * As time passes, we learn by experience what features were plain blunder=
s
> (magic_quotes?), what features should have been more strict for the sake =
of
> catching bugs without imposing too much burden on users, what features
> could have been more strict, although that would impose to write lot of
> boiler code, etc. This process does not belong exclusively to some past
> dark age of sloppy and unsecure coding practices.
>
> * The degree of wanted strictness vary depending on occasions. For exampl=
e
> when I=E2=80=99m writing a throw-away script, some notices are okay to in=
dicate
> possible problems, but I=E2=80=99m not going to write boilerplate code (o=
r, worse,
> put a @ in front of everything) just for the sake of silencing them. (But=
 I
> *certainly* do not want stupid things like mistyped constants converted t=
o
> string literals.) On the other hand, when I=E2=80=99m writing a critical =
part of an
> application, I am careful to write down everything precisely, and having =
to
> write explicitly and once for all that, yes, this precise variable must
> have that default value, is a minimal part of the time passed to write,
> re-read and review the code.
>
> =E2=80=94Claude
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--00000000000061b43a059258a78f--