> -----Original Message----- > From: Stas Malyshev [mailto:smalys...@sugarcrm.com] > Sent: Thursday, July 24, 2014 12:04 PM > To: Pierre Joye > Cc: PHP internals > Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening) > > That's called strict typing and was discussed many times. Do we really > want > another round of repeating the same arguments?
We definitely do not.. To elaborate, the notion that we already have strict class types for classes, so we should have the same thing for scalar makes no sense at all. Here's why: 1. If it was the case, we'd add this right when we added class type hints (strict class types). 2. The fact of the matter is that we did not. Why not? Because scalars in PHP behave in an inherently different way. 3. As I stated already, 'Dynamic Typing defines PHP, class type hints do not'. Class type hints were added at a *MUCH* later stage, as a part of the major rollout of the new object model of PHP 5. It was actually agreed that the *only* way we'd add such type hints is if we weren't going to have them for scalar types. What we have on the table right now - casting type hints - can be made to behave in a way that's consistent with the dynamic typing nature of PHP. My main concern about the RFC the way it stands right now is that the current direction involves E_RECOVERABLE_ERROR instead of E_STRICT or E_CAST for data loss. This results in both consistency issues with casting as well as incompatibility with the dynamic nature of PHP scalars. I know the RFC author (Andrea) disagrees with me about it, but I think we need to find a way to put this into a much wider decision. Probably the most practical thing to do is to put it as a secondary question in the RFC, although those can be tricky. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
