> -----Original Message----- > From: Andrea Faulds [mailto:a...@ajf.me] > Sent: Thursday, July 17, 2014 12:17 AM > To: Zeev Suraski > Cc: Stas Malyshev; Andrey Andreev; Rowan Collins; internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening) > > > On 16 Jul 2014, at 22:10, Zeev Suraski <z...@zend.com> wrote: > > > Stricter typing does not belong in PHP. If it did, we'd have it in > > internal functions, implicit casting and the rest of the language in > > general. We don't. > > This proposal isn't that much stricter than zpp, aside from booleans I suppose. > It's not like we allow literally anything as function arguments for internal > functions.
We do, mostly. We accept "42 ", " 42" and "42asd" as 42. We accept 1000.17 as 1000 in integer context. This is a big deal, it's not a minor detail. > > And I insist that much like you said people can catch > > E_RECOVERABLE_ERROR and turn ignore it, they can do the same with > > E_CASE - except now they won't *have* to learn about this new behavior > > unless they explicitly want to. While you think it may not be strict > > enough for some people, and I think it'd be too strict for others - > > the consistency argument should make the decision between the two > obvious. > > E_CAST is problematic. Having something we encourage some people to make > an error and some people not to means that in some cases your library works > fine and rosy in other people's environments and sometimes it crashes your 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? 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. > Also, it's worth pointing out that people will have to learn the new behaviour > anyway; no matter how we do scalar type hints, we don't currently have them, > and once implemented, everyone will have to get used to their existence (and > probably the fact they will raise E_RECOVERABLE_ERROR). 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. > > Also, I tend to agree with Stas that we can consider to do > > E_RECOVERABLE_ERROR on the obviously 'bogus' conversions - like array > > or object to int. But E_RECOVERABLE_ERROR on simple data loss is > > radically inconsistent with the rest of PHP. > > > > Sorry, I introduced hinting into PHP; I intentionally did not add > > typing for scalars as it goes against the fundamentals of the > > language, and I fought this off back in 2008, 2010 and mildly also in > > 2012. Call me persistent :) > > > > FWIW, I think the distance between where you and I stand is not that > > big - and if we go in the direction of E_CAST for data loss across the > > board (any implicit casts, not just in type hints), and > > E_RECOVERABLE_ERROR for completely broken type conversions - this is a > > big win for PHP, beyond just type hints. > > I really don't like E_CAST for the reasons mentioned above. If it's a glorified > E_NOTICE, it's pointless, 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. 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. You also don't seem to be too fond of the 'notice/strict' type errors :) 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. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
