Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34430
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: Robert Cummings <robert@interjinn.com>
Cc: Pierre <pierre.php@gmail.com>, Marcus Boerger <helly@php.net>, Gregory Beaver <greg@chiaraquartet.net>, Alain Williams <addw@phcomp.co.uk>, internals Mailing List <internals@lists.php.net>
In-Reply-To: <1199468908.6629.58.camel@blobule>
References: <477DB7BF.10201@chiaraquartet.net>
	 <20080104105558.GC7861@mint.phcomp.co.uk>
	 <477E5649.2080104@chiaraquartet.net>
	 <fe05d1540801040853q1b053a04gf4ad028e19a84e4d@mail.gmail.com>
	 <fe05d1540801040853w20c9f054i2e697764761431c9@mail.gmail.com>
	 <1463438959.20080104182050@marcus-boerger.de>
	 <fe05d1540801040923m16c616bcge29ea73f931d2072@mail.gmail.com>
	 <1199468241.6629.53.camel@blobule>
	 <1199468484.15292.156.camel@sbarrow-desktop>
	 <1199468908.6629.58.camel@blobule>
Content-Type: text/plain
Date: Fri, 04 Jan 2008 12:51:37 -0500
Message-ID: <1199469097.15292.162.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 12:48 -0500, Robert Cummings wrote:
> On Fri, 2008-01-04 at 12:41 -0500, Sam Barrow wrote:
> > On Fri, 2008-01-04 at 12:37 -0500, Robert Cummings wrote:
> > > On Fri, 2008-01-04 at 18:23 +0100, Pierre wrote:
> > > > On Jan 4, 2008 6:20 PM, Marcus Boerger <helly@php.net> wrote:
> > > > > Hello Pierre,
> > > > >
> > > > >   we never accepted this as a pro argument. Infact we often saw the
> > > > > necessaity to highlight something is optional to vote against it. We do this
> > > > > for a reason. That is we only want to support mainstream features.
> > > > 
> > > > My point of view is that this feature should be a mainstream feature.
> > > > To make it optional was to lower the issues for those who don't care
> > > > about argument strictness. We did not give them this choice for the OO
> > > > strictness.
> > > 
> > > IMHO, optionally inclusion of type hinting for functions/methods can
> > > only be a boon to code quality and readability. IMHO when a type hint is
> > > provided and a parameter doesn't match the type hint then I think a
> > > fatal error should occur. This forces the user of the function that has
> > > type hinting to ensure their data is of the correct type. This prevents
> > > accidental wrong data conversion. However, I see the other side of the
> > > coin too where automatic type conversion could be desirable also.
> > > Perhaps a mixed solution would be viable?
> > > 
> > 
> > I don't think conversion would make sense here, as PHP will
> > automatically convert the variable before you use it anyway. Hinting
> > will prevent mistakes, conversion will just try to ignore them, which is
> > what PHP does already.
> 
> I think that depends on what I do with the variable. PHP doesn't know
> how I intend to use it, and if I know I want an int and I don't want to
> test for browserland garbage in my variable everytime the function is
> called, then an automatic type conversion to int for my function can
> make perfect sense. Yes, I could force the developer using my function
> to cast the parameter as an int, but I'm certain conversion in the
> engine without a userland cast is faster, and it makes it more
> convenient to the consumer of my function since they can still treat it
> like a classic function.

Yes, but whatever you do with it (echo, store in db, etc.) PHP will
perform its default conversion routine for the variable type. You have a
point though, this is something that I've actually been debating for
some time:

function a(int $a, cast int $b) {
	
}

$a must be an int
$b will be cast to an int

I just think this is getting a little bit too complicated. Many people
on here are resistant enough to scalar type hinting because they say
it's confusing, they'll definitely be even more resistant to something
like this.

> Cheers,
> Rob.