Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106801
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAPKYkKzXAWz+=VQMHjKRyLunFnBHpvmwvYgzNJTG07BtRfSARg@mail.gmail.com>
Date: Thu, 29 Aug 2019 12:13:24 -0400
Cc: Zeev Suraski <zeev@php.net>, Aegir Leet <aegir@aegir.sexy>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <BD8A7991-A6F5-4645-8BCB-6743779819BD@gmail.com>
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> <CAPKYkKzXAWz+=VQMHjKRyLunFnBHpvmwvYgzNJTG07BtRfSARg@mail.gmail.com>
To: Chase Peeler <chasepeeler@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings
From: matthewmatthew@gmail.com (Matthew Brown)

I don=E2=80=99t think it=E2=80=99s helpful to compare C#=E2=80=99s BC polici=
es to PHP=E2=80=99s. C# is used today mostly as its architect intended at it=
s founding. PHP, having transitioned from a templating system to a fully-fle=
dged language, is used quite differently.

> On Aug 29, 2019, at 11:50 AM, Chase Peeler <chasepeeler@gmail.com> wrote:
>=20
>> On Thu, Aug 29, 2019 at 10:22 AM Zeev Suraski <zeev@php.net> wrote:
>>=20
>> On Thu, Aug 29, 2019 at 4:02 PM Aegir Leet via internals <
>> internals@lists.php.net> wrote:
>>=20
>>> 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, unforeseen=

>>> circumstances, your code could generate a notice here, probably because
>> of
>>> something that is outside of your control".
>>>=20
>>> That's how I've always treated them at least.
>>>=20
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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 somethin=
g
>>> everyone would naturally want to avoid. You don't drive your car with th=
e
>>> check engine light permanently on and say "this is fine", right?
>>=20
>>=20
>> 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.
>>=20
>> Zeev
>>=20
> 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 bac=
k
> in flexibility.
>=20
> 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 importan=
t
> 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 fo=
r
> 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.
>=20
> 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.) a=
s
> 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 t=
o
> declare variables. So, while c# might require "int i; i++;" you can achiev=
e
> the same thing in PHP with "$i++;" - neither one requires an explicit
> initialization.
>=20
> 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 considere=
d
> when weighing the pros and cons of a breaking change. That being said, I d=
o
> 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. *
>=20
> 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
> --=20
> Chase Peeler
> chasepeeler@gmail.com