Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106992
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <CAPKYkKz7waMPZReyigUmCWWXjMZpHh+K0MWEfQk2UJapmE_VxQ@mail.gmail.com>
Date: Fri, 13 Sep 2019 00:57:50 +0700
Cc: Matthew Brown <matthewmatthew@gmail.com>,
 Scott Arciszewski <scott@paragonie.com>,
 Zeev Suraski <zeev@php.net>,
 Marco Pivetta <ocramius@gmail.com>,
 PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <262D6749-66C3-4544-9FA0-32CDA6EC402A@koalephant.com>
References: <076701d56978$86020910$92061b30$@php.net>
 <CADyq6sK4HektgfDpCCFR3=bumyPaf9vn=-WdvaboHybBQKd53g@mail.gmail.com>
 <078e01d5697c$5512bc10$ff383430$@php.net>
 <CAKws9z1EBSqCFy2wD3cEV49KDSJOd6tT04PrCkxG8+3Hb6WpTA@mail.gmail.com>
 <CAPKYkKw1EU3Qp6W7b19r4kMKPD1HntH+7NQSxSiDNcLXqPERMA@mail.gmail.com>
 <CAKuGYLRWF9jnS-Zs+uRFNN1pgRSvHFpW-FChgNq9Rk282AFFGA@mail.gmail.com>
 <CAPKYkKxUyeWWZY5OyDLtAYiDUYLkwyMjuc_Wq2Y++3C9CP6G1w@mail.gmail.com>
 <CAKuGYLSub6oC=weSbjaPowhKtc3EimmFL6Tm+=D7wm7GeRLP=A@mail.gmail.com>
 <CAPKYkKz7waMPZReyigUmCWWXjMZpHh+K0MWEfQk2UJapmE_VxQ@mail.gmail.com>
To: Chase Peeler <chasepeeler@gmail.com>
Subject: Re: [PHP-DEV] Changing fundamental language behaviors
From: php-lists@koalephant.com (Stephen Reay)


> On 13 Sep 2019, at 00:41, Chase Peeler <chasepeeler@gmail.com> wrote:
>=20
> On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown =
<matthewmatthew@gmail.com>
> wrote:
>=20
>> What if Java suddenly said that all properties are suddenly private, =
and
>>> can only be accessed through getter/setter methods?
>>>=20
>>=20
>> If Java announced that the next major version was to make the change =
after
>> 95% of userland developers favoured it and over 2/3rds of their =
internals
>> team did, I'd think "huh ok I guess they have good reasons".
>>=20
>> For 20 years people have developed code based on that feature. It was
>>> never considered an error, and often not even considered bad =
practice
>>=20
>>=20
>> You seem to be arguing against *ever* changing something that a =
majority
>> once thought was good, and fundamental to a given system. Lots of =
things
>> fall into that category - restricting voting to men, segregation, =
etc.
>>=20
>=20
> Now you're just being silly. I actually don't have a problem with
> fundamental language change, provided that the positives that are =
gained
> far outweigh the negatives of the BC break and there is no other way =
to
> accomplish those positives without such a BC break.
>=20
> There are a myriad of ways to achieve what the RFC attempts to =
achieve.
> Whether that's analysis tools, custom error handlers, detailed code
> reviews, etc. Nothing prevents anyone from initializing all of their
> variables or performing as many sanity checks on a variable before
> accessing it as they want to. Nothing in the RFC is required to =
implement
> other new functionality like enums, union types, variable typing, etc.
>=20
> I also think it's a bit of a stretch to compare something like =
variable
> initialization with things that denied people their basic human =
rights.
>=20
> --=20
> Chase Peeler
> chasepeeler@gmail.com


Please, will someone arguing against making use of undefined variables a =
higher severity, explain to me why the same argument was not made for =
use of undefined constants, for which the RFC to deprecate/remove =
support, passed 41:0.

How is one undefined symbol more acceptable than another undefined =
symbol?=