Re: type hinting
| From: | Sam Barrow | Date: | Fri, 04 Jan 2008 13:20:47 +0000 |
| Subject: | Re: type hinting | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-34401@lists.php.net to get a copy of this message | ||
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.