Stas, > it's not a solution for the problem it is presented to be - it does> not make > your code more robust or fail less or saves you effort on> development I'm going to have to disagree with you there. Type hinting DOES save me a LOT of effort in development. I can stop worrying about checking to make sure the parameter that I got is what I want it to be, and just use it. The runtime will check and enforce that for me. When using things like Dependency Injection, it's crucial to have type-hints, otherwise you need to do the enforcement yourself (which a lot of people don't do).
Sure, it does introduce its own issues with throwing exceptions (I convert all ~notice errors into exceptions by default), but at least I know **why** the error happened. If the parameter is not correct, it will tell me what was passed vs what was required. Without type hinting, I would be in a situation where I would be responsible for that error (if I validated), or a weird error about an undefined method call (if not validated). Either way requires more work for regular code writing... > While the case of wrong object type is rare enough to warrant application > failure in case it happens - the case for scalar types is completely > different. It was discussed many times on the list. I half disagree here. I disagree in the thought that the rarity should dictate the check. In fact, I would argue the exact opposite. That the more often an event happens, the more pressure there should be to fix it as it would fix more really odd bugs... In this case, I agree with you that I think strict scalar hinting would not actually solve the problem. But that doesn't mean a solution shouldn't be found. I really like Rasmus's concept of "casting hints", where it would try to cast to an int and error only if it couldn't. Now, this surely would be very difficult to do in practice, and very hard to handle all the edge cases (especially when dealing with references, that could be HUGE). Anthony On Thu, Dec 22, 2011 at 2:30 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote: > Hi! > > >> What I mean is that you can catch recoverable fatal error in your error >> handler and at least be notified of what happened. Yes, you cannot go back >> in your script to corrent anything after that but you can show a detailed >> error message and send error email to developer. >> >> Just the same thing you can do when you hint class name for your input >> parameter - it will generate catchable fatal error if object is not an >> instance of expected class. > > > Exactly, strict typing has same flaws everywhere, and this is exactly the > reason it's not a solution for the problem it is presented to be - it does > not make your code more robust or fail less or saves you effort on > development - it just produces different error messages. > While the case of wrong object type is rare enough to warrant application > failure in case it happens - the case for scalar types is completely > different. It was discussed many times on the list. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
