Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37065
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain sambarrow.com from 208.70.128.73 cause and error)
To: Paul Biggar <paul.biggar@gmail.com>
Cc: Felipe Pena <felipensp@gmail.com>, internals@lists.php.net
In-Reply-To: <af54caaf0804170552vf0e0ddep7b57f6a362ffa35d@mail.gmail.com>
References: <1208404255.5665.34.camel@pena>
	 <af54caaf0804170552vf0e0ddep7b57f6a362ffa35d@mail.gmail.com>
Content-Type: text/plain
Date: Thu, 17 Apr 2008 10:01:13 -0400
Message-ID: <1208440873.32403.6.camel@sbarrow-desktop>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
From: sam@sambarrow.com (Sam Barrow)

On Thu, 2008-04-17 at 14:52 +0200, Paul Biggar wrote:
> Hi,
> 
> Your current implementation seems to be inconsistent with both itself
> and the rest of PHP. I hope this can be rectified before it is
> included. PHP is inconsisent enough without adding more.
> 
> 
> 1.) There are a number of is_* functions. It seems obvious that they
> should be consistent with this. So you're missing numeric and scalar.
> I'm not clear if there is a is_unicode(), but if so, that should be
> consistent too. (I believe scalar is particularly important, at a
> language level, since mixed and object are provided).
> 
> 2.) is_int has different semantics to the int type hint. Numeric
> strings qualify as the latter, but not the former. In general this is
> a problem. It seems type hints can only be made consistent if they
> convert the actual parameter to the type which is hinted. (Note that
> for call-by-reference, this will change the value in the caller, not
> just the copy in the callee - I think this is a good idea). As an
> example, this will fail, which it shouldnt: function y (int $x) {
> assert (is_int($x); } y ("24");

The problem with this is that there's not much point in converting the
value. PHP will do that anyway, making this kind of pointless.

> 3.) This doesnt seem to be integrated with class type hints, in the
> codebase. I wonder why that is? (I don't care all that much, I'm just
> wondering).

This works in a different way. Rather than just checking the type, it
checks the value (such as a numeric string).

Overall, I think type hinting should work by checking the type. If it
does not match, raise an error. For example, int means int, not numeric
string.
This only serves to include an additional type juggling system into php,
which is very confusing.