Re: Type hinting

From: 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.

« previous php.internals (#48604) next »