Re: Strict typing (was: Typehints)
| From: | Stas Malyshev | Date: | Tue, 10 Aug 2010 22:46:40 +0000 |
| Subject: | Re: Strict typing (was: Typehints) | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-49290@lists.php.net to get a copy of this message | ||
Hi!
1. right now we *have* strict type checks for classes and arrays in theBecause classes and arrays were never intechangeable types and there was never implicit or explicit conversion between SplRecursiveTreeIterator and Zend_Pdf_Generator - it doesn't even make sense to suggest it. There always was conversion between int and string or int and bool. These two things are completely different.form of "classname" or "array"
2. the strict scalary type hint patch reuses this same syntax in theIt's not a good thing. As I mentioned, primitive types and classes are very different in their use cases and established patterns in PHP. Primitive types are largely interchangeable, classes are not. (As for arrays, arrays really should be a class by their usage patterns etc. but for historic reasons... you know)form of<type-name> to do the same thing in function arguments
3. we have casting type hints in the rest of the code in the form ofJust to make it simpler and less confusing, of course. It's nothing like language having two features that look almost exactly the same but work in different way, and using plenty of ()s is an added bonus for all Lisp fans out there."(int)".
Some people don't like strict typehints, but the syntax as it currently is regarding type hints is *consistent*. Now, to allow both strict and casting hints, the logical step seems to be, to give the weak typehint advocates their tool as well:Calling something that works completely differently from all the established patterns of PHP - like internal functions, etc. - "*consistent*" requires totally new definition of this word. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227