Re: [RFC] Type hints (parameter and return value)

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