On Fri, 2008-01-04 at 10:55 +0000, Alain Williams wrote: > On Thu, Jan 03, 2008 at 10:36:15PM -0600, Gregory Beaver wrote: > > Hi all, > > > > As someone who has dealt with many scripts written by others as well as > > many of my own in a large-scale project (PEAR). I can say with absolute > > certainty that scalar type hints would not make my job easier. > > > > In fact, it would make it harder. Many of the functions I work with > > require varied input and almost always require some kind of validation > > of that input. A built-in procedure that would either end execution > > with a fatal error or suddenly jump execution to a global error handler > > that has no idea of the context in which the error was triggered is > > almost as useful to me as a PHP extension that runs the pump on an > > You are missing the point. > If you want your function to take an argument of arbitrary type, then > you simply don't give a type hint[**] > > [**] I suppose that we might implement the type hint 'mixed' which would > have the same effect as no type hint. Some people might like this from > the 'internal documentation' point of view.
I was thinking about this, a "mixed" type hint which doesn't do anything. Would be very easy to add. > > Where is the increased value? Saving a few keystrokes of validation? > > No. You still need to validate the input for range, or is_numeric() or > > No. The point is NOT to save input ($_GET, etc) validation -- that will > still need to be done; the point is to help pick up programming errors > where you accidentally get the type wrong. > > Granted: some idiots will use it as cheap input validation, but it is > difficult > to help some people. Exactly. This is not intended for $_REQUEST stuff. This is intended for internal function interaction, configuration variables, etc. All post/get data is inputted as strings, so this doesn't apply there. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
