Type hinting

Andi,

The existing functionality is very simple (no RFC) needed. It allows for
scalar type hints and ensures that the Z_TYPE of the parameter matches the
indicated type in the declaration, any mistmatch results in an error.

So which RFC should I be reviewing? Does this RFC reflect what Ilia's
patch does? I just want to be sure we are talking about the same thing
and can review and comment on it in detail. We've had many discussions
on this topic over the years and different people had different things
in mind so we need to make sure we have a good structured discussion
(and documented via RFC).

Andi

-----Original Message-----
From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
Sent: Saturday, May 22, 2010 1:39 PM
To: Josh Davis
Cc: Zeev Suraski; internals@lists.php.net
Subject: Re: [PHP-DEV] Type hinting

As you wrote, you worked on PHP's type system which is dynamic,
really cool, juggles strings with ints and what not. However, the
topic here is the type hinting system. As far as I know, there's
no
"weak" type hinting; if a method signature hints for an array and is
given an integer, it throws a catchable fatal error. Therefore, as a
user, what I am familiar to is a strict type hinting system.
Anything else would feel inconsistent to me.

can we please just stop calling a something a "type hinting" system,
which leads
to a catchable fatal error when the type does not strictly match?
thats a very
misleading euphemism. its simply strict typing, it has nothing to do
with hinting.

anyway, yes there is a proposal for an actual hinting system as Zeev
has pointed
out just a few mails early in the thread than yours:
http://wiki.php.net/rfc/typecheckingstrictandweak

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

--
To unsubscribe,
visit:
http://www.php.net/unsub.php

can we please just stop calling a something a "type hinting" system, which leads to a catchable fatal error when the type does not strictly match? thats a very misleading euphemism. its simply strict typing, it has nothing to do with hinting.

It definitely isn't strict either:

$ php -r 'function errh() {} set_error_handler("errh",
E_RECOVERABLE_ERROR); function bar(foo $x) {echo "hello world\n";}
bar(1);'
hello world

heh ... you are selling recoverable errors as anything but a solution to display something else than a white screen?

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

At 01:01 23/05/2010, Hannes Magnusson wrote:

As you wrote, you worked on PHP's type system which is dynamic,
really cool, juggles strings with ints and what not. However, the
topic here is the type hinting system. As far as I know, there's no
"weak" type hinting; if a method signature hints for an array and is
given an integer, it throws a catchable fatal error. Therefore, as a
user, what I am familiar to is a strict type hinting system.
Anything else would feel inconsistent to me.

I agree. function foo(array $x) {} foo(123); doesn't cast int(123) to
array(123) so introducing different meaning for scalar types feels
very very wrong.

You're ignoring one simple fact - in PHP, scalar types are
interchangeable. Unlike array->scalar which has always been a corner
case and a sketchy one (and I said numerous times that had I rewrote
the language now, array->scalar conversion would have probably
resulted in an error) - string->number, number->string,
string->boolean conversions are a cornerstone of the language. If
you don't like the fact that PHP's scalar types are interchangeable -
you're in the wrong language!

In terms of consistency, the difference between array type hinting
and scalar type hinting you allude to is negligible in comparison to
the inconsistency with, well, just about every other part of the
language - operators, control structures and built-in functions
(expecting sqrt("64") to fail, since sqrt() expects a
number? expecting if (7) to fail, since it expects a
boolean?). Auto-converting type hinting extends the same semantics
available to internal functions (through zend_parse_parameters()) to
userland functions. That consistency is by far the most important IMHO.

Zeev

Hi!

I agree. function foo(array $x) {} foo(123); doesn't cast int(123) to
array(123) so introducing different meaning for scalar types feels
very very wrong.

Casting integers to arrays never happened in PHP. Casting strings to
integers and back always happened. Including in internal functions. Now
internal and user functions would work differently, and half of PHP
would be dynamically typed while another half would be statically typed.
I fail to see how it may be a good thing.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

On Monday 24 May 2010 12:09:30 am Zeev Suraski wrote:

I have to say that I don't really see the logic in "either it should
be identical to PHP's conversion rules or it should be 100.000%
different (strict)". Adding strict typing would be the largest
inconsistency in PHP's core syntax, ever.

For that reason, I prefer pretty much any variation of the proposed
solution over strict type checking.

I see three key options going forward:

1. Implement the table along the lines of what it looks like now,
   perhaps with minor changes.
2. Implement identical conversion rules to the ones that exist in
   PHP; That effectively turns type hinting into scalar casting
   operators (not saying that's a bad thing!)
3. Implement identical conversion rules to the ones that exist in
   PHP, except for when they really suck. Namely, lose the
   array->scalar conversions and silent conversions of non-numeric
   strings to numbers.

I personally lean towards #3.

Zeev

#3 is the one that seems like it would be most useful in practice, with one
caveat. If given an input of float(5.4) and a function parameter specified as
int, there is data loss if you just do the equivalent of (int)$foo so that
falls into the "really suck" category and should also explode. (float(5),
however, has no data loss in that operation so it's safe.)

I don't know if there's performance issues to address with that addition that
may nix it, but that would be the ideal.

--Larry Garfield

Hi!

I see three key options going forward:

1. Implement the table along the lines of what it looks like now,
   perhaps with minor changes.
2. Implement identical conversion rules to the ones that exist in
   PHP; That effectively turns type hinting into scalar casting
   operators (not saying that's a bad thing!)
3. Implement identical conversion rules to the ones that exist in
   PHP, except for when they really suck. Namely, lose the
   array->scalar conversions and silent conversions of non-numeric
   strings to numbers.

I'm for 3, Array->scalar must die, as for non-numeric to numbers, I
don't have strong opinion as I see no point in it, IMO if it failed, I'd
be OK with it.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

I see three key options going forward:

1.  Implement the table along the lines of what it looks like now, perhaps
   with minor changes.
2.  Implement identical conversion rules to the ones that exist in PHP; That
   effectively turns type hinting into scalar casting operators (not saying
   that's a bad thing!)
3.  Implement identical conversion rules to the ones that exist in PHP,
   except for when they really suck.  Namely, lose the array->scalar
   conversions and silent conversions of non-numeric strings to numbers.

Given this is a new feature, my preference is #1, with the addition of
the scalar and numeric hints mentioned upthread for less strict
checking. I see scalar type hinting as a way of saying "I want a
variable of type X", not "I want a variable that may have been lossily
coerced into type X"; the developers mentioned in the RFC who are
presently unaware of PHP's typing system strike me as being unlikely
to use type hinting regardless of how it's implemented.

That said, I don't think #3 would be the end of the world, either. My
vote is admittedly a little selfish; it just doesn't line up as well
as #1 with what I'd actually want to use scalar type hinting for.

Adam

At 03:53 24/05/2010, spam@geleia.net wrote:

As one of the key people who designed PHP's type system I consider
strict type checks completely alien to and counterintuitive in PHP
and am therefore pushing to implement 'weak' typing instead, in a
way that's consistent and familiar to users.

I agree. I added to the RFC a table with the current behavior of
current behavior of zend_parse_parameters (not sure if I should, feel
free to move it elsewhere). There are many differences between two. I
think the conversions should either be the same or it should be strict.

Are users supposed to distinguish "string" as it appears in the
documentation from this new "string" in the functions' declaration?
Adding another inconsistency to PHP is not a very good idea, in my
opinion.

I have to say that I don't really see the logic in "either it should
be identical to PHP's conversion rules or it should be 100.000% different
(strict)". Adding strict typing would be the largest
inconsistency in PHP's core syntax, ever.

I disagree. The === operator already checks the type of the variables.
Saying that the PHP programmers shouldn't have to worry about the type of
the variables (that it's just an implementation detail) is pure fantasy.
Let's say I want to check whether some arbitrary user input is 0.

if (array_key_exists('quantity', $_POST) &&
!is_array($_POST['quantity']) && $_POST['quantity'] == 0) { ... }

Now I have the condition evaluate to true if the user input was "abc". I'm
sure I come up with lots of examples where the type is important in PHP
and the programmer must be aware of it.

For that reason, I prefer pretty much any variation of the proposed
solution over strict type checking.

I see three key options going forward:

1. Implement the table along the lines of what it looks like now,
   perhaps with minor changes.
2. Implement identical conversion rules to the
   ones that exist in PHP; That effectively turns type hinting into scalar
   casting operators (not saying that's a bad thing!)
3. Implement identical conversion rules to the ones that exist in PHP,
   except for when they really suck. Namely, lose the array->scalar
   conversions and silent conversions of non-numeric strings to numbers.

That said, I don't think strict type checking is the best option. I just
think it's better than inventing a new complex set of rules that are
inconsistent with everything else. Otherwise, an "int" could mean that the
type is int (is_int), that zend_parse_parameters would accept it with the
flag "l" or "L", or that it is an int in this new weak sense. Maybe we
could also add "is castable to an int" (which works with arrays, but not
with objects unless they implement get/cast). That would put us at 4
different meanings.

I think the best option is to align the type checking with
zend_parse_parameters (this is not the same as an implicit cast) and make
it stricter. This includes:

• disallow string to float/int when it contains non-numeric characters
  (includes "123abc")
• disallow string/float to int when it causes overflow instead of the
  current behavior (triple cast (long)(unsigned long)(long long)). "L" would
  retain the current behavior.

Although a depart from backwards compatibility, I doubt this would cause
much brekage.

--
Gustavo Lopes

Hi Zeev:

1. Implement the table along the lines of what it looks like now,
   perhaps with minor changes.
2. Implement identical conversion rules to the ones that exist in PHP;
   That effectively turns type hinting into scalar casting operators (not
   saying that's a bad thing!)
3. Implement identical conversion rules to the ones that exist in PHP,
   except for when they really suck. Namely, lose the array->scalar
   conversions and silent conversions of non-numeric strings to numbers.

My preference depends on what option 3 really means and what tweaks would
be made to 1. I like the RFC's "list of examples" table over the
recently added "zend_parse_parameters" table.

Important changes to the example table seem to be:

• string representations of int would be okay for int and float
• string representations of float would be okay for float
• maybe have null and '' be okay as bool.

On a side note, I hope the hinting will allow the ability to do something
something like "int|null" for graceful handling of optional parameters.

Thanks,

--Dan

--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409