> On 11 Feb 2015, at 21:30, Zeev Suraski <z...@zend.com> wrote: > >> -----Original Message----- >> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] >> Sent: Wednesday, February 11, 2015 8:37 AM >> To: Xinchen Hui; Andrea Faulds >> Cc: PHP Internals >> Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints >> >> On 02/10/2015 07:57 PM, Xinchen Hui wrote: >>>> am I wrong?! >>> seems I am wrong with this, it's a false alarm... it can restore >> automatically. >> >> Yeah, declare() doesn't span files so that isn't a problem. >> >> My worry is still the lack of type coercion for internal calls. > > There's also some pretty interesting analysis on this proposal - based on > some real world experimentation - from Benjamin Eberlei - bit.ly/1vl0UED
I disagree with some aspects of the blogpost: > enabling strict mode completly defeats the purpose, because now we are forced > to convert manually, reimplementing weak type hinting in our own code This isn’t true at all. The key difference between explicit conversions and implicit conversions is that they’re, well, *explicit*. You can see them, they are blatantly obvious, if you use grep you can find them. Implicit conversions, while they can sometimes be great, happen silently and automatically - if they screw up, it can be hard to track down where the conversion is taking place. With explicit conversions, you’re converting once and you know you’ve converted. With implicit conversions, you have no idea where and how often values are being converted. > We write code with casts already, the scalar type hints patch is not > necessary for that! Only a superficial level of additional safety is gained, > one additional check of something we already know is true! Yet in the previous part he was explaining how existing code doesn’t use casts and would need them added… so therefore, this thing *isn’t* already known to be true, and the blogpost is self-contradictory. > strict mode is useless for library developers, because I always have to > assume weak mode anyways. I don’t really understand at all… either he doesn’t understand the proposal (which guarantees you get the types you ask for), or it’s a reference to the claim from the previous paragraph, which I’ve already responded to. > In a well designed application or library, the developer can already trust > the types of his variables today, 95% of the time, without even having type > hints, using carefully designed abstractions (example Symfony Forms and > Doctrine ORM): No substantial win for her from having strict type hints. Yet he was previously explaining how, actually, data coming in from web requests isn’t the correct types. > In a badly designed application, the developer is uncertain about the types > of variables. Using strict mode in this scenario she needs to start casting > everywhere just to be sure. In an application using strict mode everywhere with scalar type hints everywhere, you can’t possibly be uncertain about the types of variables. … there’s a lot more in that blog post I could disagree with, but I won’t bother. Benjamin has his reasons for not liking strict mode. That’s fine. But if PHP adds strict mode, it has zero effect on him. > If you've voted on this RFC or intend to vote - please spend the few minutes > to read through his blog post. It does a good job at actually illustrating > what life would look like if this rubber ends up meeting the road. Anthony Ferrara also had his own analysis which showed some of the problems with weak type hinting, and where strict types can be beneficial: http://blog.ircmaxell.com/2015/02/scalar-types-and-php.html I would suggest people read that blog post before voting, as well. It points out some real-world examples of where weak typing in PHP can be insufficient (div), or even downright dangerous (curlopt). -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
