Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37067
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.162.180 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=pnrzF2bxfSnIL6c1G35GYgm4zvnSYh0x1DdMCRoczw/LKw1PBbo80VscAy6faA83g9GWJ8E49NIRYftgOWhGxe1dkkgvDbfy6dgDNJWr+tWzXINOjcpqWbreqo0+uPblUuM5x5uR3WTrBkWgeqYHSsGhlqU5rA2CrWdRgJLedaY=
Message-ID: <af54caaf0804170728i5d44c9c8sa84147359d2da21e@mail.gmail.com>
Date: Thu, 17 Apr 2008 16:28:38 +0200
To: "Sam Barrow" <sam@sambarrow.com>
Cc: "Felipe Pena" <felipensp@gmail.com>, internals@lists.php.net
In-Reply-To: <1208440873.32403.6.camel@sbarrow-desktop>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1208404255.5665.34.camel@pena>
	 <af54caaf0804170552vf0e0ddep7b57f6a362ffa35d@mail.gmail.com>
	 <1208440873.32403.6.camel@sbarrow-desktop>
Subject: Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
From: paul.biggar@gmail.com ("Paul Biggar")

Hi Sam,

On Thu, Apr 17, 2008 at 4:01 PM, Sam Barrow <sam@sambarrow.com> wrote:
\>  > 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.

That is not quite correct. PHP's weak typing is somewhat inconsistent,
and in the example I included, it will not coerce the value of $x. An
'int' type hint is not the same as is_int (), which is a mistake.

It seems the easiest thing is to make the conversion mandatory at
call-time. Alternatives would include weakening is_int(), or making
the 'int' hint fail for numeric strings (as you mention below). I
believe these two solutions are not as good.



>  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.

This is one alternative. The aim should be consistency (or as you say,
avoiding confusion). This weak typing is already part of the language,
so I don't believe it is inconsistent, though your suggestion clearly
is. However, it is more consistent than, and therefore preferable to,
the current patch.



Thanks,
Paul

-- 
Paul Biggar
paul.biggar@gmail.com