[RFC] Type hints (parameter and return value)

Arvids Godjuks wrote:

So full syntax will be like this
function (integer) test(integer $value) { ... }

I guess you are right: int and integer seem to be aliase and both check
for int or numeric strings, not the type int.
It is also not clear if (string) accepts ints/floats which are often
valid values.

I think a table of which type hint accepts which values would be useful.

And there also remains the issue with the keywords where I'd like to be
enlightened :-)

• Chris

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.

If inside y() you have something like:

for( $i = 0; $i < $x; $i++ )

you will end up converting $x to integer $x times ... which will eat
CPU if $x is large -- I tried it.

An:
assert (is_int($x))
followed by:
$x = (int)$x
is the way to go.

This only serves to include an additional type juggling system into php,
which is very confusing.

If you don't understand it: don't use it.

--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h

Hi Sam,

> > 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

Hi!

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.

There would be a point since PHP might convert to different type that
you intended. Think of $foo = "My age is $age". If $age is supposed to
be int, then converting int hint might help.

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.

What code scenario would make it necessary to distinguish between number
stored as string and number stored as binary?

This only serves to include an additional type juggling system into php,
which is very confusing.

There's already type juggling in PHP, and if you find it confusing, you
find whole PHP and whole set of dynamic languages very confusing. I
guess maybe C or Java would work better then :)

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

Hi Stanislav,

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.

If you talk about consistency, you should remember that right now no
function and no feature in PHP relies on strict checking of primitive types.

Please try to minimize redundant response (at least within 15 mins). I
think we all got that you are against type hints in PHP, that's plain
wrong to do it, etc, etc. Thanks for your understanding (reply to my
ICU questions instead :-D,

Cheers,

Pierre
http://blog.thepimp.net | http://www.libgd.org

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.

If you talk about consistency, you should remember that right now no
function and no feature in PHP relies on strict checking of primitive types.

That is not the case (or I am very much mistaken). In particular,
is_int, which I mentioned in my email, is predicated on the IS_LONG
type only.

Paul

--
Paul Biggar
paul.biggar@gmail.com

I think that the typehints should be strict, if you don't want
strictness, don't use type hints.

Note that right now we already have non-strict typehints in most of the
internal functions, so you are using them if you use PHP.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

+1 for strict types.

That way it will be simple:

• Don't need - then don't use at all
• You need it - you use it fully.

One thing than left to clearfy - do we allow to hint only part of args or do
we go the road "if hint args, then hint them all!" (I'm personaly for second
one - be strict)