Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106800
MIME-Version: 1.0
References: <CAF+90c9Kc6m_bv=aJxbD3-RmnNXXLqv6mPjHp7U7qxX_ck27qw@mail.gmail.com>
 <CAF+90c-+ewSj2oTASZMrENuaDRA3ys=LdAwwjjbVjA2v7Es+Kg@mail.gmail.com>
 <CAJHtznzx6u7h2dYtAMTtgpzGnVYgYRA0JvJ5p=4-koor-Wdnbw@mail.gmail.com>
 <33b4068a-3b32-4904-a033-4ff3f28e1161@aegir.sexy> <1EDD1FE6-9AB8-4CDF-8EE4-416C18390725@gmail.com>
 <bb322cbd-c283-ea77-8889-619f3927854c@aegir.sexy> <CAJHtznxf=FAL_aWz1eL5fS1xQ1NRKae+4UqE7pVSn-9cG7ScpA@mail.gmail.com>
In-Reply-To: <CAJHtznxf=FAL_aWz1eL5fS1xQ1NRKae+4UqE7pVSn-9cG7ScpA@mail.gmail.com>
Date: Thu, 29 Aug 2019 11:50:57 -0400
Message-ID: <CAPKYkKzXAWz+=VQMHjKRyLunFnBHpvmwvYgzNJTG07BtRfSARg@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Aegir Leet <aegir@aegir.sexy>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006f53e405914379ae"
Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings
From: chasepeeler@gmail.com (Chase Peeler)

--0000000000006f53e405914379ae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 29, 2019 at 10:22 AM Zeev Suraski <zeev@php.net> wrote:

> On Thu, Aug 29, 2019 at 4:02 PM Aegir Leet via internals <
> internals@lists.php.net> wrote:
>
> > I know what the manual says about notices. But I don't agree with
> > interpreting "could happen in the normal course of running a script" as
> > "it's perfectly fine if this part of your code triggers a notice
> > consistently and every time it goes down this particular code path".
> > Rather, I've always interpreted this as "under certain, rare, unforesee=
n
> > circumstances, your code could generate a notice here, probably because
> of
> > something that is outside of your control".
> >
> > That's how I've always treated them at least.
> >
>
> And that's entirely within your right to do so - but what the manual says
> is accurate.  Calling me delusional in my interpretation of it is somewha=
t
> awkward (to put it mildly), I have a pretty good idea of why we added the
> different error levels - I wrote much of it myself.
>
> The whole point of having notices as something that's separate from
> warnings is that they have different semantics, and that semantics is
> captured very accurately in the manual.  They are used to mark issues whi=
ch
> may be problems, but may also be perfectly fine (unlike warnings, which
> generally speaking mean that something bad happened, but not bad enough t=
o
> halt execution).  Notices were meant to help you implement a more strict
> style of coding, and they may help you catch certain types of bugs, but y=
ou
> can have perfectly working, bug-free code that generates notices.
>
> Regardless of the exact semantics, don't you think a program that generat=
es
> > a constant stream of notices is a bit strange? That sounds like somethi=
ng
> > everyone would naturally want to avoid. You don't drive your car with t=
he
> > check engine light permanently on and say "this is fine", right?
>
>
> Except you can purposely turn off this 'check engine' light, never to see
> it again if you choose to.  And that it's really not at all similar to
> 'check engine', but a lot closer to 'check cleaning fluid', or even 'clea=
n
> windshield' (if cars had a dashboard light for that).  Even that is not a
> good analogy - as folks often actually purposely write code that generate=
s
> notices (which would be purposely hidden, either by error_reporting setti=
ng
> or using @) that is 100% bug-free and working as intended.  So no, there'=
s
> nothing strange about it if you buy into that approach.  If you don't (an=
d
> I know you don't) - that's absolutely fine - it's up to you.
>
> Zeev
>
I just wanted to bring up a few other points. First, as I think Stanislav
has done a good job of pointing out, the flexibility of PHP is one of its
greatest features. The nice thing about a flexible and forgiving language
is that you can always put additional things in place on top of it to make
it more strict and rigid if you want. Once you force a language to be
strict and rigid, however, it's much harder, if not impossible, to add back
in flexibility.

A lot of my emails on this thread have been focused on the burden to
developers caused by the BC break. While I still think that is an important
consideration, it distracted me from my initial view which was we shouldn't
do this because it's just a bad idea. I understand all of the arguments for
enforcing variable initialization. I agree with most of them as well.
However, I think there are a myriad of ways that individuals and teams can
do that enforcement without forcing it on every single developer whether
they want it or not.

A lot of comparisons have been made to other languages. I do a lot of work
with javascript and I have a good amount of experience with c# as well.
I've used many other languages at times (c, c++, java, perl, ruby, etc.) as
well. In c#, you don't have to initialize your variables - you have to
declare them. Some types, like ints, are automatically initialized to 0
unless explicitly initialized to something else. PHP doesn't require you to
declare variables. So, while c# might require "int i; i++;" you can achieve
the same thing in PHP with "$i++;" - neither one requires an explicit
initialization.

A few people have referred to the fact that I have instances of undeclared
variables as technical debt. As I said earlier, I've engaged in these
discussions because I don't think just calling something technical debt
should be justification for a change. The fact that a large number of
developers might have technical debt in a certain area should be considered
when weighing the pros and cons of a breaking change. That being said, I do
NOT consider such code to be technical debt or bad code that needs to be
fixed. The only way it becomes either of those if with the implementation
of this RFC. It's a bit disingenuous to tell developers they have to make
large changes, and when they push back, tell them it's their fault for
accruing so much technical debt - when it's the RFC itself that actually
causes the technical debt to begin with! *I will no longer engage in
conversations on this topic that relate to how you think my company should
conduct business or prioritize development. *

Finally, since people seem hell bent on turning PHP into a language that
operates like all the others, instead of letting it keep its unique
qualities that make it great and different, I asked a c# developer I know
about how Microsoft deals with breaking changes. Here was his response:
"I=E2=80=99ve never heard of a breaking change when new versions of C# are
released. There are occasionally breaking changes when upgrading to a new
version of .NET, but they always (as far as I=E2=80=99m aware) have a way t=
o
prevent the change from breaking anything by adding a parameter the app=E2=
=80=99s
configuration."

--=20
Chase Peeler
chasepeeler@gmail.com

--0000000000006f53e405914379ae--