Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34419
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain sambarrow.com from 205.234.132.11 cause and error)
To: Gregory Beaver <greg@chiaraquartet.net>
Cc: Alain Williams <addw@phcomp.co.uk>, internals Mailing List <internals@lists.php.net>
In-Reply-To: <477E5649.2080104@chiaraquartet.net>
References: <477DB7BF.10201@chiaraquartet.net>
	 <20080104105558.GC7861@mint.phcomp.co.uk>
	 <477E5649.2080104@chiaraquartet.net>
Content-Type: text/plain
Date: Fri, 04 Jan 2008 12:21:12 -0500
Message-ID: <1199467272.15292.153.camel@sbarrow-desktop>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] type hinting
From: sam@sambarrow.com (Sam Barrow)

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.
> 

Are you suggesting that if a function requires an integer, string, and
object, we use is_int, is_string, and is_object to trigger errors? What
if we have 50 functions like this?

With type hinting:

function a(int $a, string $b, object $c) {
	
}

Without type hinting:

function a($a, $b, $c) {
	if (!is_int($a)) {
		trigger_error(E_WHATEVER, 'Argument 1 to function a() must be an
integer.') ;
	}
	if (!is_string($b)) {
		trigger_error(E_WHATEVER, 'Argument 2 to function a() must be an
integer.') ;
	}
	if (!is_object($c)) {
		trigger_error(E_WHATEVER, 'Argument 3 to function a() must be an
integer.') ;
	}
}