Re: Type hinting
| From: | Eloy Bote Falcon | Date: | Wed, 02 Jun 2010 07:29:06 +0000 |
| Subject: | Re: Type hinting | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-48604@lists.php.net to get a copy of this message | ||
Hi!
2010/6/2 Stas Malyshev <smalyshev@sugarcrm.com>
> Hi!
>
>
> Is there some other reason / use case for wanting exceptions? So, I
>> mean, where is the use case where '123abc' will be passed to a
>> type-hinted field where you could catch the exception and do something
>> meaningful to carry on with the execution of the program other than
>> simply error-ing out?
>>
>
> Pretty much everywhere. Suppose you have form with, say, 2 fields and first
> field does not validate. Maybe you want to check the second field too and
> give the user both errors if they are both wrong?
>
> In general, looking at strict typing as user input validation mechanism is
> a very bad idea. There are specialized use input validation
> functions/classes/frameworks, and one should use them.
>
> --
> 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
>
>
I agree with you. The type hinting is not a replacement for the sanity check
of the user input but a proper way of defining what type of data your
functions should work with, so it's OK to trigger errors when data loss
happens.
When you have function foo(int &$bar) the data loss will affect the
application in the same way that an undefined var would do; so the E_NOTICE
error level seems the best approach to me. And when the data conversion is
not possible (e.g. object to numeric) just trigger an E_FATAL. Let the top
level users take care of the input because I think that language features
like this type hinting are for the low level of the development.
Regards,
Eloy Bote Falcón.