> -----Original Message----- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Thursday, February 26, 2015 9:54 PM > To: Zeev Suraski > Cc: Mike Willbanks; Dan Ackroyd; Theodore Brown; internals@lists.php.net > Subject: Re: [PHP-DEV] A different user perspective on scalar type > declarations > > Zeev, > > >> With the current coercive proposal, you will still need to worry > >> about the > >> types: https://wiki.php.net/rfc/coercive_sth#coercion_rules > > > > That's true, but a lot, lot less. > > 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 efforts involved in both cases, clearly, the amount of effort with coercive is a lot smaller - as you let the language do most of the work for you. In the few cases where it might be overzealous - it'll alert you to it, and you can easily fix it. In the strict case, yes, you would pretty much have to audit your entire app. Yes, you can do it gradually file by file over the course of a few years - but the combined cost is a lot higher, there would be a lot more code changes and the resulting code - in all likelihood - hiding more bugs due to a lot more explicit casting. > >> Passing boolean(false) where an integer is expected will generate an > >> error. > >> This is a common practice, specifically around internal functions. > >> Example: > >> > https://github.com/sebastianbergmann/phpunit/blob/a4e23a10d4eeea5fd9f > >> e8916859a07430b94cf42/src/Util/ErrorHandler.php#L58 > > > > It's actually not nearly as common as one might think, and arguably - > > it's may be hiding bug or at least some misunderstanding about the > > semantics of the argument (not always, but sometimes). Warning about > > it (as deprecated) makes perfect sense. I'm going to send some data > > from real world apps later today or early tomorrow. Spoiler - not a > > lot of breakage at all, and coercive rules seem to have a remarkably > > good > signal to noise ratio. > > 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. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
