Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106725 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 69622 invoked from network); 28 Aug 2019 15:58:35 -0000 Received: from unknown (HELO mail-vs1-f42.google.com) (209.85.217.42) by pb1.pair.com with SMTP; 28 Aug 2019 15:58:35 -0000 Received: by mail-vs1-f42.google.com with SMTP id x20so1818525vsx.13 for ; Wed, 28 Aug 2019 06:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dxgzqvf3gB92Sgksnf9/LAJL4KjvmQ/D259tdMWCBY4=; b=USbat1K193Z/10ah3tnG7ZAREw9swKLa8B8tpvrNcL0bpQZggzsdJawrHbrKJeNltW vwwhdjr2PYEZkjWjVziYByV2hAco94GEkBkWkQzxfdGvFeFoIvgicOD62IR+d1+f0bEo ZXlK1Rt/JbL5sBqw5Ixv8na81bDpILQ/zBd8RxjbeVjff9QGH2cIKHPLxAT0PZUGr7Vq dAAu0gsxndStt4wAVONojJPlWMuLq5AOMCOSsvWlKOEWCW7B7WkrOKWWRCUwSJ7BGNp0 l4nLd21RCZAdDLLQtWkppaafGke8t6gIn8iBhP2axJo81D8Sjp911EYOWF4lt+Y3FuRq pVcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dxgzqvf3gB92Sgksnf9/LAJL4KjvmQ/D259tdMWCBY4=; b=BfmIv9nBnqBZ8uuc3EYGd1Ygu88Qq/ems5pBXmh0+X93XICZX5Dnv/xbnoCIkpC50V 3E00xywRTSiH4KtoDx5mZXBqmOL8BAPubGQXY9AZBlbw9HDQ3O+d4jVVQylbZDab3shy ueA0ckbyB0DDPAIJE19uudU1AHEo1Dbh8uzRI8oupmmBicTBDjamUD5wa9H3/w1hvSvl oyTBipuIFNUznIkg9xTQLO+9KaUDAsod2xhElHmn9Gq43Dsi8V7l0NcXftfZTQbqODWX bTRW0G609BW5uaW6NLJYZ7ByIc22Lpx2kpcwjGxkAuNTw52GW3MwyY07kzWJui8s5eQB r3Sg== X-Gm-Message-State: APjAAAVYPYkms34qNAw8bXOa/xH/d7o0BeIE/JlBMeL9p1zMX1whfnBt RLGmbcM1dsJJ1oUwgS29MtpEyHMyF4136aqSrkI= X-Google-Smtp-Source: APXvYqxkZIr/IR6U3Bfu/FxBvm89m9ZfGcTsw2IkaAZGYb3nTMqVHyXa0MmRcuAMu6VsL71aipxPyYetGjWkBLj0kVg= X-Received: by 2002:a67:da1e:: with SMTP id v30mr2380124vsj.209.1566999043999; Wed, 28 Aug 2019 06:30:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 28 Aug 2019 09:30:32 -0400 Message-ID: To: Zeev Suraski Cc: Nikita Popov , PHP internals Content-Type: multipart/alternative; boundary="000000000000618eb005912d6579" Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings From: chasepeeler@gmail.com (Chase Peeler) --000000000000618eb005912d6579 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 28, 2019 at 8:35 AM Zeev Suraski wrote: > On Wed, Aug 28, 2019 at 2:10 PM Nikita Popov wrote: > > > On Wed, Aug 28, 2019 at 12:41 PM Zeev Suraski wrote: > > > >> > >> > >> On Wed, Aug 28, 2019 at 12:33 PM Nikita Popov > >> wrote: > >> > >>> Hi internals, > >>> > >>> I think it's time to take a look at our existing warnings & notices in > >>> the > >>> engine, and think about whether their current classification is still > >>> appropriate. Error conditions like "undefined variable" only > generating a > >>> notice is really quite mind-boggling. > >>> > >>> I've prepared an RFC with some suggested classifications, though > there's > >>> room for bikeshedding here... > >>> > >>> https://wiki.php.net/rfc/engine_warnings > >> > >> > >> Specifically on undefined variables, the way we deal with them has > little > >> to do with register_globals. It's behavior you can find in other > >> dynamic languages (e.g. Perl), and allows for certain code patterns > (which > >> rely on the automatic creation of a variable whenever it's used in write > >> context, and on a default known-in-advance value in case it's used in a > >> read context). It's fine not to like this behavior or the code patterns > >> that commonly rely on it (e.g., @$foo++), but it's intentional and isn't > >> related to any historical reasons. > >> > > > > This argument makes sense for arrays and objects (and I don't promote > > undefined index/property to exceptions for that reason), but I don't > think > > it holds any water for simple variables. Writing @$counts[$key]++ is a > lazy > > way to count values and avoid ugly boilerplate for if > > (isset($counts[$key])) { $counts[$key]++; } else { $counts[$key] = 1; }. > > But @$foo++ is just a really bad way of writing either $foo++ or $foo = > 1. > > Outside of variable variables, the concept of a conditionally defined > > variable just doesn't make a lot of sense. > > > > This example has nothing to do with arrays. There are many code patterns > in which relying on this behavior makes perfect sense for folks who are a > lot less strictly-minded. For example: > > foreach (whatever) { > if (sth) { > @$whCount++; > } > } > > Yes, it may be painful for many eyes that $whCount is not explicitly > initialized, but the above code is perfectly legitimate, warning-free > notice-compliant code since forever. Moreover - this isn't legacy - there > are a lot of folks who appreciate this precise behavior, which is > documented and works as expected for the last 20+ years. > > Or: > > if ($bookCount>0) { > $suffix = 's'; > } > > print "$bookCount book$suffix"; > > These are just two simple cases I bumped into myself recently. There's an > infinite supply of more of those where these came from. > > > > > >> I think many (if not all) of your proposals make sense, but most of them > >> make sense as an opt-in - perhaps using something similar to Perl's > strict > >> mode (which incidentally, changes the way the language treats undefined > >> variables in exactly the same way). This would also provide a > future-proof > >> solution for additional similarly-themed proposals (such as strict ops, > >> etc.). > >> > > > > I don't think this is an appropriate use of an opt-in. It's a case where > > we can balance language cleanup with backwards compatibility concerns. > Code > > that works after this proposal will also work before it, and as such > there > > is no danger of ecosystem bifurcation that would need to be addressed by > an > > opt-in. > > > > Calling this 'cleanup' is opinionated, and avoiding bifurcation by forcing > that opinion on everyone isn't a very good solution for those who have > other opinions. While the opinion that variables must not be used before > being initialized is obviously a valid one - it is just that, one valid > opinion - and there are others. PHP never took this opinion as an > axiomatic requirement (and not because of register_globals) - instead, the > intent was to have a default value for uninitialized variables - a > consistent, documented behavior since the dawn of the language. Can this > be problematic under certain situations? Absolutely. Can it be useful in > other cases? Sure (which is why it's very common). A great deal of folks > both rely on this behavior and *like *it. Those who don't (and there's > plenty of those as well of course) - always had a reasonable solution of > enabling E_STRICT and enforcing E_STRICT-compliant code. I still think > that having a strict mode (which can encompass strict types, strict ops, > stricter error behavior, etc.) makes a lot of sense and would arguably be a > superior option for the many folks who prefer a stricter language - but > there's simply no way we can change one of the most fundamental behaviors > of the language and force it down people's throats - not only because it > breaks compatibility, but because it breaks how many people are used to > write their PHP code. Perl provided stricter-liking folks with a solution > in the form of 'use strict;' decades ago; JS did something similar much > more recently. Neither of these created any sort of bifurcation - it's a > simple, sensible solution that has virtually no downsides. > > While I like Zeev's idea of making it opt-in, I think that a deprecation path is needed at the very least. I think this has the potential to be an even bigger issue to deal with than short tags. At least short tags have been discouraged for a long time. The first short tags RFC would have probably lead to a delay in upgrading to 8.0. This RFC would pretty much guarantee never being able to upgrade to 8.0 until we've totally retired our legacy code base... which will probably be just in time for PHP 28.0 - assuming the PHP project isn't dead at that point due to this RFC. > Zeev > -- Chase Peeler chasepeeler@gmail.com --000000000000618eb005912d6579--