On Fri, 2008-01-04 at 09:52 -0600, Gregory Beaver wrote: > 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[**] > > > But I *don't* want my functions to take an argument of arbitrary type - > it is in fact you who are missing the point. A type hint is a poor > solution to a real problem that is much more easily solved via simple > input validation and graceful error handling. The current situation in > PHP provides a much more flexible solution to the same problem. > > Many users out there are confused about simple things like the result of > 1 === "1" versus 1 == "1". The fact is that scalar types are simply not > strict enough to warrant a type hint. An object of class X is immutable > - you either have that or a subclass. An array is an array, and can't > look like anything else. Integers, floats, strings are much more gray > area, and much less likely to provide good, clear input to check against > a type hint. > > Also, you and many who are in favor of type hints seem to forget that > part of PHP's strength is the ability to distribute and use code written > by other people. I guarantee that regardless of whether I choose to use > type hints, someone whose code I will have to use will be using type > hints, forcing me to deal with them. Imagine a program uses exceptions > for error handling, and you wish to use a library that has type hints. > Now, you can't catch problems using this program except via fatal error, > or worse, an error handler that has only a backtrace from which to grab > context. > > [**] 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. > > > > > >> 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. > This is just the point that appears to be lost on advocates for scalar > type hints - this work of picking up programming errors should be > performed in development, not in production, and type hint as warning > does nothing to assist debugging. In the error log, there is no > backtrace, so all you know is that on line X in file Y invalid input was > passed to a function. No context, no reproduce steps, and no backtrace > to see the logic train.
That's not true. You can easily set up your error handler to throw an exception, which will provide a full backtrace. And type hinting will help to catch these errors in development, rather than finding out that all of your users have their email addresses stored as "Array" in your database. > Greg > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
