Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83924 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 79373 invoked from network); 26 Feb 2015 20:24:27 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Feb 2015 20:24:27 -0000 Authentication-Results: pb1.pair.com header.from=ircmaxell@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ircmaxell@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.52 as permitted sender) X-PHP-List-Original-Sender: ircmaxell@gmail.com X-Host-Fingerprint: 209.85.215.52 mail-la0-f52.google.com Received: from [209.85.215.52] ([209.85.215.52:39223] helo=mail-la0-f52.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AC/3F-32582-AF08FE45 for ; Thu, 26 Feb 2015 15:24:27 -0500 Received: by labgq15 with SMTP id gq15so13444625lab.6 for ; Thu, 26 Feb 2015 12:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NM3d2XCnubiHOBzHn2zZtcVBmkhNBzORSeffR7shvUs=; b=mMaNRhtVnkEOLMesh6rW90Q72gAGWtmFd6a7by7vKw6SnSyWV09ghFFt9Aqt8EQ5lR yAjG4zNshyPZjdtqJ658boWEd8vyrO90mHx3ws3aHwEjszhvcAlP10sTcJUFJdepi0+X o/q+RhW1cUUULnxlmu70GK7y9M+SEG5Pa2y6wXswVUTGP24gPjXOpGdGD/HoOHApm0SK +pG2+qiWS1/DIAHwl+mpl6X4hxmfK2bJjNt4CzVr4AMshKOZHFiIJJacLWkN+uottJKw zE4Zx6sLsElLDsfifyJskMghmoXA4+s3A18L1wqQiaxUJbESjnMuvwyotCV4sM/El0/4 /QsQ== MIME-Version: 1.0 X-Received: by 10.152.27.164 with SMTP id u4mr450318lag.45.1424982263742; Thu, 26 Feb 2015 12:24:23 -0800 (PST) Received: by 10.25.43.9 with HTTP; Thu, 26 Feb 2015 12:24:23 -0800 (PST) In-Reply-To: <42bc7c079a67fe1aa982b5c55ecc2f16@mail.gmail.com> References: <3d639901ae85227b219e7ee59b3140fe@mail.gmail.com> <42bc7c079a67fe1aa982b5c55ecc2f16@mail.gmail.com> Date: Thu, 26 Feb 2015 15:24:23 -0500 Message-ID: To: Zeev Suraski Cc: "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] A different user perspective on scalar type declarations From: ircmaxell@gmail.com (Anthony Ferrara) Zeev, >> We apparently have a different definition of "less". Your proposal >> requires >> you to worry about every type in every line of code that ever existed. >> Yes, >> there are fewer dangerous type change errors, but you need to look at >> every >> line of your application to find them. > > Realistically, that's not how it's going to be done, but rather through > testing (either running a test suite, manual tests, or even running it in > production and seeing deprecation warnings in the log, for which you'd have > years to fix). I don't see application audits being invoked for this, not > by a long shot. > > When I say you need to worry about them a lot less - I mean that you can get > 90%+ of the benefits of strict mode, for ALL of your code, with a tiny > fraction of the hassle. > From past posts, it's very clear you believe that large projects would > gradually migrate to being strict across the board. If we compared the Well then, you've heard things I've never said. I've said, time and time again, that weak and strict should live side by side **in the same application**. That you'd keep the outside code weak, and the critical parts will be strict. That's why dual mode is good. Not because it gives a "migration path", but lets people choose what's appropriate for their needs. So no, I don't believe that large projects would or should migrate to be strict across the board. If I did, I wouldn't make it per-file. >> If Symfony or PHPUnit didn't error in these cases in more than one place, >> I'd >> be inclined to agree with you (about not being as common as one might >> think). But considering two of the best architected and tested >> applications in >> the ecosystem both error in non-trivial amounts, I think it's fair to >> say... > > I think that once we see some more conclusive test results from these > projects, that go slightly deeper than just running the code and seeing > deprecation warnings - a lot more people would be inclined to agree. > Perhaps even you :) > > What constitutes major breakage in your mind, for a project as large as > PHPUnit, that's acceptable to fix over the course of several years? 20 > issues? 100? 200? 500? More? > What if many of these issues are actually pointing out potential real world > problems, and changing them would result in better more robust code? > >> >> The difference is with the dual-mode RFC you can choose not to have >> >> to cast and keep everything as-is today (or more specifically, you >> >> need to explicitly choose strict mode). And you can have user-land >> >> behave identically to internals **in both cases**. >> > >> > Put another way, coercive gets to keep a single, sensible conversion >> > rule-set in PHP - with relatively minor updates needed over the course >> > of several years. And contrary to what might be implied here, it >> > would require a LOT less casting - while still taking advantage of >> > much better data sanitation. >> >> I think you're REALLY downplaying the level of effort that's required for >> the >> updates you're requiring users make. And that scares me. > > Given that I actually ran Magento, Drupal, WordPress and both the Symfony > and ZF2 skeleton apps with the new coercive ruleset, and I already know > there's no reason at all to be scared. More on that later today or early > tomorrow - running more tests. They run without triggering E_DEPRECATED errors? Because that means they will break with 8 (which by your own words is closer to 2-3 years out than 9-10). Anthony