[PHP-INTERNALS] [RFC] Type hints (parameter and return value)

What about types like
array
mixed

Ok, for "mixed" we may not use type hinting at all - does patch allow to
hint only part of function args?
If we have a function, witch takes as 1st argument array or string and other
args should have strict types or just use call like myFunc(Array($string),
.....) ? This is just to know this for sure.

2008/4/17, Felipe Pena <felipensp@gmail.com>:

Array is already built in, and for mixed, as you already mentioned, indeed
no type hinting. I definitely want this implemented, +1 from me.

I don't like the difference between
function (int) test($value) { ... }
and
function test(integer $value) { ... }

I don't think we should introduce two different names for something
which is basically the same. Even if there is (as I guess) a slight
difference (int *really* being int and integer allowing strings
containing numbers), which makes the WTF factor even higher IMHO.

Also about "New tokens (new keywords)": I haven't tried the patch so
excuse me asking. Does this mean $this->string is invalid because string
is a new keyword? Then I'd be strongly against having these new keywords.

Is there any performance impact for people not using type hints?

Just to make it clear: I think type hinting is a Bad Idea(tm) anyway but
*if* it is implemented I think you should consider the above points.

- Chris

Christian Schneider



First is function return value should be int, second is function arg should
be int.
So full syntax will be like this

function (integer) test(integer $value) { ... }

That means function takes an integer as argument and returns integer value.
If any is violated - Catchable error will be thrown.

That's my understanding of this patch. Some more examples

function (resource) query(string $table, array $where = array(), array
$limit = array()) { ... }

function (array) getData(string $table, array $limit = array(0, 20), array
$where = array()) { /* cals query and generates an array from result */ }

etc.

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

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");

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

I hope we can get these ironed out.

Thanks in advance.
Paul

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

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.
If you don't understand it: don't use it.

Hi Sam,

On Thu, Apr 17, 2008 at 4:01 PM, Sam Barrow wrote:
\> > 2.) is_int has different semantics to the int type hint. Numeric
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.


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

Hi!
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.
What code scenario would make it necessary to distinguish between number
stored as string and number stored as binary?
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 :)

I understand it very well, but why have a whole other system of type
juggling? That would be duplicating type juggling functionality that's
already in there.

It's the same system. The same system that makes internal functions work.

Hi!
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.

Hi Stanislav,
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,

Hi!
Against strict type hints, yes.

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

Hi!
Read that "no function except for a tiny handful of very special cases
like is_* and serializes and probably one or two other functions that I
forgot", ok?

Hi,

is_* are the important functions, since they are the ones which most
resemble the type hints under discussion. Up until now, anyone
implementing this in user-land would use is_int(). It makes perfect
sense that type hints should mimic this behaviour. Not doing so would
be very inconsistent, and so confusing.


Paul

Hi!
No, you shouldn't do that - there's absolutely no reason to accept 1 and
reject '1', unless you have some very rare and special circumstance. If
you are using is_int for that, your code is wrong.
Could we stop using word "consistent" to replace "I like it"?

No comment.

Cheers,

Yes, I phrased that badly. I believe it is fair to say that there
would be confusion over why is_int may fail after an 'int' type hint.
More generally, I think it is difficult to explain why an int type
hint does not guarantee an int.


That is very subjective. I doubt there is 'one true style' of PHP,
despite suggestions I see about 'the PHP way'. But let us suppose you
would use an int cast instead to ensure you have an int (by type, not
coerced value). The behaviour I recommend is also consistent with
casting. It would be syntactic sugar for

function ($x) { $x = (int) ($x); ... }



I am very deliberately not using "consistent" to replace "I like it",
except in the sense that I like consistency. It makes no sense to find
that you do not have an int, when you specify you must. I very much
mean consistency, and do not have a preference for the approach,
except that only one seems perfectly consistent in this case, which is
why I have recommended it.


Paul

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

regards,
Derick

+1

- Mark

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.

+1

Derick Rethans wrote:

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

It may be that a parameter CAN be mixed, so a lack of a type hint
should be supported even if strict type hinting is used/implemented.
Maybe a type hint of mixed?

Of course; we don't make type hinting necessary, just type the variable
name with no type hint as you would now and no type check is performed.

No, just use in the arg that you want.

Example:
http://felipe.ath.cx/diff/tests/param_tests/param_type_hint_016.phpt

Hello Felipe,

please do not allow non optional parameters after optional parameters.
Also default value NULL seems pretty odd for a numeric type and it might
be an idea to only allow types matching the type hint. But I guess it is
in line the current type hints and a good solution to mark those as not
passed.

You took care of reflection parameter but not of reflection
method/function.

What I do not like about the return type hint patch is that it adds the
native types upfront. This is actually all that is discussable. Return
type hints themselves were already agreed on. That said we only need to
think whether your syntax is ok. And from that perspective you get my
vote, too. So how about a limited patch first that does not introduce
native types, only implements return type hints and does also add
reflection for it.

marcus

Friday, April 18, 2008, 1:52:22 PM, you wrote:




Best regards,
Marcus