Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107002 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 24916 invoked from network); 12 Sep 2019 20:48:59 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 12 Sep 2019 20:48:59 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 7A5BF2CAEF4 for ; Thu, 12 Sep 2019 11:24:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS36024 206.123.114.0/23 X-Spam-Virus: No Received: from mail1.25mail.st (mail1.25mail.st [206.123.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Thu, 12 Sep 2019 11:24:54 -0700 (PDT) Received: from [10.0.1.86] (unknown [49.48.245.106]) by mail1.25mail.st (Postfix) with ESMTPSA id BDBE860500; Thu, 12 Sep 2019 18:24:39 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) In-Reply-To: Date: Fri, 13 Sep 2019 01:24:36 +0700 Cc: Matthew Brown , Scott Arciszewski , Zeev Suraski , Marco Pivetta , PHP Internals List Content-Transfer-Encoding: quoted-printable Message-ID: <39CD5157-5758-4CBB-8838-C42C7426A03A@koalephant.com> References: <076701d56978$86020910$92061b30$@php.net> <078e01d5697c$5512bc10$ff383430$@php.net> <262D6749-66C3-4544-9FA0-32CDA6EC402A@koalephant.com> To: Chase Peeler X-Mailer: Apple Mail (2.3445.104.11) X-Envelope-From: Subject: Re: [PHP-DEV] Changing fundamental language behaviors From: php-lists@koalephant.com (Stephen Reay) > On 13 Sep 2019, at 01:07, Chase Peeler wrote: >=20 >=20 >=20 > On Thu, Sep 12, 2019 at 1:58 PM Stephen Reay = wrote: >=20 > > On 13 Sep 2019, at 00:41, Chase Peeler = wrote: > >=20 > > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown = > > 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 >=20 >=20 > 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. >=20 > How is one undefined symbol more acceptable than another undefined = symbol? >=20 > First of all, I wasn't as involved with this list back then as I was = now. However, I can see a fundamental difference in the two. Not needing = to initialize variables just for the sake of initializing them (e.g. = just doing $i++ without $i=3D0 before it) is something that is going to = behave as expected almost all of the time. When it doesn't, you can = easily initialize $i to a non-zero value, or, you can initialize it to = zero if you want - it doesn't hurt anything. >=20 > An undefined constant getting converted to a string, though, is much = less likely to be the intended behavior. String literals are required to = be in quotes. Constants can never be in quotes. Assuming that the token = that looks like a constant, but can't be because the constant didn't = exist, so, we'll pretend it's a string even though it doesn't match the = proper syntax for such a token is drastically different than assuming = the variable you are incrementing that wasn't initialized is 0, or, that = the variable you are concatenating to, but wasn't initialized, is an = empty string.=20 >=20 > Finally, let's pretend that the undefined constants RFC was a horrible = RFC that shouldn't have passed. The fact that it did has no impact on = whether or not this RFC should pass.=20 >=20 > --=20 > Chase Peeler > chasepeeler@gmail.com Apologies if you thought I was specifically replying to you Chase, I = simply hit reply-all to the last message I had. The RFC I referred to explicitly describes the use-case for the = (mis-)feature it removed: > The current behaviour appears to have been added as an attempt to = guess the user's intention, and continue gracefully. Sounds familiar, doesn=E2=80=99t it? =E2=80=9CIf I write $foo++ and $foo = is undefined, it should know what I mean=E2=80=9D. > The value of keeping the current behaviour would be for programs = written to deliberately take advantage of it. In particular, I have seen = sample code of the form $_GET[bar] where bar is taken to be the string = key bar.=20 So, it clearly was (ab)used. IMO this also flies in the face of the =E2=80=9Cwe can=E2=80=99t change = behaviour=E2=80=9D argument - bare word strings were added around 20 = years ago, and yet not a single person thought it worthwhile voting = against the deprecation and removal of this behaviour?