On 16 Jul 2014, at 22:42, Zeev Suraski <z...@zend.com> wrote: > That's the point. Many people will not consider this an error, myself > included, and I suspect that also Rasmus and Andi who created the language > concept for the language many many years ago. PHP doesn't consider it to > be an error today across the language. > Can you explain how a library that works for you won't work for someone > else?
Someone relies on E_CAST not being fatal. Someone wanting strictness makes an error handler making it fatal. Bam, an awful lot of code breaks. E_CAST is a terrible idea if we want software interoperability. We can’t have it both ways; type hints must be either strict or not strict, if they’re conditionally strict by environment then we will destroy our ecosystem. Of course, we could just make it a glorified E_NOTICE, but then what’s the point? E_NOTICE already exists. > The code inside the library will ALWAYS get valid input, in both options. > Always. There's no difference. If it misbehaves, it will be because of > the supplied argument - and it will be clear to the user. Much like in > most of the cases when an API doesn't work right, it's because it's not > being used correctly and not because of a bug in the implementation. Right. The code inside the library will, sure. The point is that the library will now crash the program because it wasn’t written with a strictly-interpreted E_CAST in mind. > Of course they'd have to learn something new - the new syntax at the very > least. But they wouldn't have to learn something new and inconsistent. It’s inconsistent anyway. Type hints don’t act like zpp does, unless you want me to make them emit E_WARNING and return NULL. > It's not, not at all. It helps you clean your code from these issues *IF* > you care about them, and it doesn't bug others who don't. E_NOTICE's and > E_STRICT work remarkably well - I know many people who choose to ignore > them, and many people who wouldn't deploy code before it's 100% clean of > them. While I'm sure you have an opinion on what this setting should be > (and I might even be able to guess it), PHP's philosophy was letting the > users (developers) choose. As I’ve explained earlier, letting them choose to make this fatal would be a horrible, horrible idea. > Ultimately it seems you dislike a very fundamental concept in PHP, that > scalar types are 'transient' and can convert without notice depending on > the context. Nope, I have zero problem with this basic feature. I may have in the past, sure, but I have come to like PHP’s weak typing. Also, they *don’t* universally convert without notice, they only do when they fit a certain set of conditions. This RFC just makes userland type hints (which much of the community apparently wants to be fully strict?) have a slightly tighter ruleset that’s more logical, if somewhat inconsistent with the rest of PHP. > You also don't seem to be too fond of the 'notice/strict' > type errors :) E_NOTICE makes sense, I just don’t think it’s the right approach for type hints. (Though speaking of which, the default object casting handler’s behaviour of just emitting a notice instead of actually failing is really weird. Why is that an E_NOTICE? What on earth is the failure case for, then? Surely it’s the caller’s job to emit the notice?) > I can understand that, but nonetheless, the former is a > very basic fundamental part of PHP and we shouldn't add features that go > against it, and the latter is a concept that's been serving us well for > years. This is obviously a matter of opinion, but I really don’t think this RFC goes against that. This RFC encourages automatic type conversion, it’s just slightly less lenient than zpp is to help write less buggy software. I suppose it fits the existing mould, where internal functions are really tolerant and won’t make much fuss (a mere E_WARNING and NULL) while userland type hints are much more draconian. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
