Hi Sam,
On Thu, Apr 17, 2008 at 4:01 PM, Sam Barrow <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
