There has been quite a bit of discussion on this list, IRC,
developer meetings, etc... about introduction of type hinting to
PHP. Most people appear to think that this would be a good idea, but
there is a reason why it is not in PHP already. The main source of
conflict appears to be that in some cases typical type hinting is
just too strict for PHP's typeless nature (most people expect that
"1" == 1, while int type hint would definitely reject string "1").
Personally, I disagree with that opinion, but I can understand
people who raise that issue. At work we've been using PHP 5.2 with
type hinting for nearly 2 years now with great success, it makes
code much easier to read and understand and the security benefit of
type hinting is not to be under valued. In many cases type hinting
can present a last line of defense against unexpected input for
numeric fields, which are typically abused to do SQL injection.
[snip]
My hope is that the latest changes will allow this to become a
standard part of PHP.

+1 (+1000, actually :)

-- Gwynne

There has been quite a bit of discussion on this list, IRC, developer
meetings, etc... about introduction of type hinting to PHP. Most
people appear to think that this would be a good idea, but there is a
reason why it is not in PHP already. The main source of conflict
...

Another desirable result of type hinting is that it would strengthen
reflection ... one use of that would be automatic generation of
WSDL files. This is something that I am currently struggling to do,
not helped by the completely cr*p documentation of this - I am not
talking about PHP documentation here by W3 & other places :-(

+1 to type hinting.

--
Alain Williams
Linux/GNU 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
Past chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h

Ilia Alshanetsky schrieb:

about introduction of type hinting to PHP

About the "introduction of scalar type hinting" you mean? :-)

I am all for this, but I think it would be wrong to add this in 5.3.X.

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

Hi Ilia,

This is great.

I've taken a few hours this morning to port my 5.2 type hinting patch to
5.3. In recognition of a need for a more 'flexible' numeric type I've
introduced (numeric) type hint that would allow bool/int/float data types as
well as a string containing a numeric entity as identified by
is_numeric_string(). For completion i've also added (scalar) data type that
will allow any scalar data element.

I think this will go a long way to addressing people's concerns when
this came up previously.

The patch is available here: http://ia.gd/patch/type_hint_53.txt

I presume the idea is that some people (if they so chose) would want
to type hint every parameter in their program. To facilitate this, I
might suggest a "mixed" hint (like in the docs), and a null hint
(though I'm not sure if it would be called "null" or "unset" or both).

Finally, I don't want to ruin this, but last time there was
disagreement over whether numbers should be coerced to the specified
types, or left alone. What does your patch do?

ie function x (int $x) { echo is_int ($x); } x ("5");

Thanks,
Paul

It should be noted that this is not the first idea for type hints, that
credit goes to Hannes Magnusson who had posted a similar patch on the
internals list back in 2006. Also, back in 2008 Felipe Pena wrote a type
hinting patch for PHP that is available on wiki.php.net.

--
Paul Biggar
paul.biggar@gmail.com

Hi!

The patch is available here: http://ia.gd/patch/type_hint_53.txt

Technical comment: as this patch changes binary API this shouldn't
happen in 5.3 branch. So maybe it's better to make it for 6.

As for the idea itself, it is obvious that many people like it, I would
just note that it would produce a confusion for some people due to the
fact that true, 1, 1.0, b'1' and '1' now become incompatible values and
(once you start using typehints, of course) you'd have to explicitly
convert them. That would lead people to stuff their code with explicit
type conversions, which doesn't add to code cleanness. This also means
that internal functions and user functions would behave differently with
regard to type conversions.

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

The patch is available here: http://ia.gd/patch/type_hint_53.txt

It is missing minor build fix for ext/reflection, see
http://pastebin.com/f50db9aa1

Other then that, I'm definitely +1 on this

-Hannes

Ilia Alshanetsky wrote:

There has been quite a bit of discussion on this list, IRC, developer
meetings, etc... about introduction of type hinting to PHP.
[..]

My hope is that the latest changes will allow this to become a standard
part of PHP.

+1

[..]

• Mark

The main source of conflict appears to be that in some cases typical
type hinting is just too strict for PHP's typeless nature (most
people expect that "1" == 1, while int type hint would definitely
reject string "1").

To be fair, this is really my compliant, but:

I think, for consistency, it should behaviour like
zend_parse_parameters, hence not being overly strict, and should set
the variable to it casted to the expected type. If it behaves
differently to zend_parse_parameters then it'll be annoying that
substr(), whose first parameter is a string, behaves differently to
function foobar(string $what) when passed an int, for example.

I'd expect:

function foo(string $bar) {
var_dump($bar);
}

foo(1234);

To output:
string(4) "1234"

As this appears to be consistent with what internal functions that use
zend_parse_parameters do. I don't want PHP to become any more
inconsistent with itself than it already is.

--
Geoffrey Sneddon
<http://gsnedders.com/

Ilia Alshanetsky wrote:

There has been quite a bit of discussion on this list, IRC, developer
meetings, etc... about introduction of type hinting to PHP. Most people
appear to think that this would be a good idea, but there is a reason
why it is not in PHP already. The main source of conflict appears to be
that in some cases typical..

This would be a great feature IMO. However, like others, I'm a bit
concerned on how can consistency with internal functions be achieved.

I don't think it would be that beneficial without method overloading by
method signature. In fact, type hinting would be a step foward in that
direction, and my head it makes sense that both features arrive
togheter. I know nothing about php internals, method overloading by
signature is something too hard to implement?

And, while type hinting and method overloading are things I really miss
in php when comparing to other languages (amongst other thinkgs) and I
do think they would be fantastic, I think HEAD is more suited for thoses
changes rather than 5.3 branch. (But I must confess I loved LSB and
Closures in 5.3 :) )

Regards
Rodrigo Saboya

I've taken a few hours this morning to port my 5.2 type hinting patch to 5.3.
In recognition of a need for a more 'flexible' numeric type I've introduced
(numeric) type hint that would allow bool/int/float data types as well as a
string containing a numeric entity as identified by is_numeric_string(). For
completion i've also added (scalar) data type that will allow any scalar data
element.

The patch is available here: http://ia.gd/patch/type_hint_53.txt

+1

regards,
Derick

--
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
twitter: @derickr

Hello,

For what it's worth, a large +1 from me.

One concern I do have, however, is that the addition of scalar type hints
will put more attention to the lack of method overloading. Right now methods
can accept multiple values due to the type-lessness, and while it will
remain a possibility, code with type-hints usually is a lot clearner. To
demonstrate:

class Example {
public function setValue (int $value) {}
public function setValue (string $value) {}
}

While there are two obvious solutions for this (not using type-hinted
parameters and using setIntValue/setStringValue) I think inclusion of a
patch like this would be a good moment to overthink overloading like this.

Peter

"Ilia Alshanetsky" ilia@prohost.org wrote in message
news:FC14FAFE-6785-4067-9B49-9FC14F159C52@prohost.org...

I've taken a few hours this morning to port my 5.2 type hinting patch to
5.3. In recognition of a need for a more 'flexible' numeric type I've
introduced (numeric) type hint that would allow bool/int/float data types
as well as a string containing a numeric entity as identified by
is_numeric_string(). For completion i've also added (scalar) data type
that will allow any scalar data element.

The patch is available here: http://ia.gd/patch/type_hint_53.txt

It should be noted that this patch is fully compatible with opcode caches
and and requires no changes on the part of an opcode cache such as APC to
work.

My hope is that the latest changes will allow this to become a standard
part of PHP.

Ilia Alshanetsky

P.S.

It should be noted that this is not the first idea for type hints, that
credit goes to Hannes Magnusson who had posted a similar patch on the
internals list back in 2006. Also, back in 2008 Felipe Pena wrote a type
hinting patch for PHP that is available on wiki.php.net.

Hi,

I'm a userland developer with limited C skills, and while I don't yet
have an
opinion on the whole type enforcing issue, aside from a fear of
libraries abusing
it, I'd like to propose a little change in the patch.

Is it possible that instead of an E_RECOVERABLE_ERROR, an Exception to
be thrown? I don't know whether InvalidArgumentException satisfies the
semantics,
but it's a step in that direction.

There has been quite a bit of discussion on this list, IRC, developer
meetings, etc... about introduction of type hinting to PHP. Most
people appear to think that this would be a good idea, but there is a
reason why it is not in PHP already. The main source of conflict
appears to be that in some cases typical type hinting is just too
strict for PHP's typeless nature (most people expect that "1" == 1,
while int type hint would definitely reject string "1"). Personally,
I disagree with that opinion, but I can understand people who raise
that issue. At work we've been using PHP 5.2 with type hinting for
nearly 2 years now with great success, it makes code much easier to
read and understand and the security benefit of type hinting is not to
be under valued. In many cases type hinting can present a last line of
defense against unexpected input for numeric fields, which are
typically abused to do SQL injection.

I've taken a few hours this morning to port my 5.2 type hinting patch
to 5.3. In recognition of a need for a more 'flexible' numeric type
I've introduced (numeric) type hint that would allow bool/int/float
data types as well as a string containing a numeric entity as
identified by is_numeric_string(). For completion i've also added
(scalar) data type that will allow any scalar data element.

The patch is available here: http://ia.gd/patch/type_hint_53.txt

It should be noted that this patch is fully compatible with opcode
caches and and requires no changes on the part of an opcode cache such
as APC to work.

My hope is that the latest changes will allow this to become a
standard part of PHP.

Ilia Alshanetsky

P.S.

It should be noted that this is not the first idea for type hints,
that credit goes to Hannes Magnusson who had posted a similar patch on
the internals list back in 2006. Also, back in 2008 Felipe Pena wrote
a type hinting patch for PHP that is available on wiki.php.net.

--
Ionut G. Stan
I'm under construction | http://igstan.blogspot.com/

2009/7/1 Ilia Alshanetsky ilia@prohost.org:

There has been quite a bit of discussion on this list, IRC, developer
meetings, etc... about introduction of type hinting to PHP. Most people
appear to think that this would be a good idea, but there is a reason why it
is not in PHP already. The main source of conflict appears to be that in
some cases typical type hinting is just too strict for PHP's typeless nature
(most people expect that "1" == 1, while int type hint would definitely
reject string "1").  Personally, I disagree with that opinion, but I can
understand people who raise that issue. At work we've been using PHP 5.2
with type hinting for nearly 2 years now with great success, it makes code
much easier to read and understand and the security benefit of type hinting
is not to be under valued. In many cases type hinting can present a last
line of defense against unexpected input for numeric fields, which are
typically abused to do SQL injection.

I've taken a few hours this morning to port my 5.2 type hinting patch to
5.3. In recognition of a need for a more 'flexible' numeric type I've
introduced (numeric) type hint that would allow bool/int/float data types as
well as a string containing a numeric entity as identified by
is_numeric_string(). For completion i've also added (scalar) data type that
will allow any scalar data element.

The patch is available here: http://ia.gd/patch/type_hint_53.txt

It should be noted that this patch is fully compatible with opcode caches
and and requires no changes on the part of an opcode cache such as APC to
work.

My hope is that the latest changes will allow this to become a standard part
of PHP.

Brilliant stuff Ilia!

One thing I noticed in the patch is:

"+<ST_IN_SCRIPTING>("string"|"binary"|"unicode") {

• return T_STRING_HINT;
  +}
  "

which makes sense if we keep for PHP6 but doesn't for 5_3 which afaik
doesn't have (unicode) casting yet :) I think that's nitpicking I
agree and I just want to make sure that this doesn't become a
documentation issue for people who'd think you can hint using unicode
or even see article saying you can hint with unicode.

Makes sense for PHP6 though but since you merged your patch from 5.2 I
figured I could ask :)

Apart from that this is awesome and am I glad that we are not trying
to cast automatically!

+1

--
Slan,
David

Hi Ilia,

Your patch doesn't support a "null" (or maybe it should be called
"unset") type check. Its uses would be rare, but I think it should be
present for completeness.

Thanks,
Paul

There has been quite a bit of discussion on this list, IRC, developer
meetings, etc... about introduction of type hinting to PHP. Most people
appear to think that this would be a good idea, but there is a reason why it
is not in PHP already. The main source of conflict appears to be that in
some cases typical type hinting is just too strict for PHP's typeless nature
(most people expect that "1" == 1, while int type hint would definitely
reject string "1").  Personally, I disagree with that opinion, but I can
understand people who raise that issue. At work we've been using PHP 5.2
with type hinting for nearly 2 years now with great success, it makes code
much easier to read and understand and the security benefit of type hinting
is not to be under valued. In many cases type hinting can present a last
line of defense against unexpected input for numeric fields, which are
typically abused to do SQL injection.

I've taken a few hours this morning to port my 5.2 type hinting patch to
5.3. In recognition of a need for a more 'flexible' numeric type I've
introduced (numeric) type hint that would allow bool/int/float data types as
well as a string containing a numeric entity as identified by
is_numeric_string(). For completion i've also added (scalar) data type that
will allow any scalar data element.

The patch is available here: http://ia.gd/patch/type_hint_53.txt

It should be noted that this patch is fully compatible with opcode caches
and and requires no changes on the part of an opcode cache such as APC to
work.

My hope is that the latest changes will allow this to become a standard part
of PHP.

Ilia Alshanetsky

P.S.

It should be noted that this is not the first idea for type hints, that
credit goes to Hannes Magnusson who had posted a similar patch on the
internals list back in 2006. Also, back in 2008 Felipe Pena wrote a type
hinting patch for PHP that is available on wiki.php.net.

--
Paul Biggar
paul.biggar@gmail.com

Hi Ilia,

There has been quite a bit of discussion on this list, IRC, developer
meetings, etc... about introduction of type hinting to PHP. Most people

RE your second patch, from http://ilia.ws/patch/type_hint_53_v2.txt

Index: Zend/zend_compile.c

RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.109
diff -u -p -a -d -u -r1.647.2.27.2.41.2.109 zend_compile.c
--- Zend/zend_compile.c 7 Jun 2009 15:46:51 -0000 1.647.2.27.2.41.2.109
+++ Zend/zend_compile.c 4 Jul 2009 17:20:50 -0000
@@ -1511,10 +1514,9 @@ void zend_do_receive_arg(zend_uchar op,
zend_error(E_COMPILE_ERROR, "Default value for parameters with a
class type hint can only be NULL");
}
}

•   } else {
  

•   	cur_arg_info->array_type_hint = 1;
  

•   	cur_arg_info->class_name = NULL;
  

•   	cur_arg_info->class_name_len = 0;
  

•   	break;
  

•   case IS_ARRAY:
  

So, to signify an array type hint, we used to use 1, and we now use
IS_ARRAY, which is 4. I'm not 100% sure that's an ABI problem, but I
just wanted to check.

		if (op == ZEND_RECV_INIT) {
			if (Z_TYPE(initialization->u.constant) == IS_NULL ||

(Z_TYPE(initialization->u.constant) == IS_CONSTANT &&
!strcasecmp(Z_STRVAL(initialization->u.constant), "NULL"))) {
cur_arg_info->allow_null = 1;
@@ -1522,6 +1524,56 @@ void zend_do_receive_arg(zend_uchar op,
zend_error(E_COMPILE_ERROR, "Default value for parameters with
array type hint can only be an array or NULL");
}
}

•   	break;
  

•   /* scalar type hinting */
  

•   case IS_BOOL:
  

•   case IS_STRING:
  

•   case IS_LONG:
  

•   case IS_DOUBLE:
  

•   case IS_RESOURCE:
  

•   case IS_NUMERIC:
  

•   case IS_SCALAR:
  

•   case IS_OBJECT:
  

•   	if (op == ZEND_RECV_INIT) {
  

•   		if (Z_TYPE(initialization->u.constant) !=
  

class_type->u.constant.type && Z_TYPE(initialization->u.constant) !=
IS_NULL) {

•   			zend_error(E_COMPILE_ERROR, "Default value for parameters with
  

%s type hint can only be %s or NULL",
zend_get_type_by_const(class_type->u.constant.type),
zend_get_type_by_const(class_type->u.constant.type));

That error says NULL is allowed for scalars, which I presume is wrong.

•   /* type forcing via cast */
  

•   case FORCE_BOOL:
  

•   case FORCE_STRING:
  

•   case FORCE_LONG:
  

•   case FORCE_DOUBLE:
  

•   	if (op == ZEND_RECV_INIT) {
  

•   		switch (Z_TYPE(initialization->u.constant)) {
  

•   			case IS_ARRAY:
  

•   			case IS_OBJECT:
  

•   			case IS_RESOURCE:
  

•   				zend_error(E_COMPILE_ERROR, "Default value for parameters with
  

a forced type of %s can only be a scalar",
zend_get_type_by_const(class_type->u.constant.type));

I think a default parameter of the wrong type must signify a
programmer error, so should be forbidden.

Index: Zend/zend_execute.c

RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.716.2.12.2.24.2.44
diff -u -p -a -d -u -r1.716.2.12.2.24.2.44 zend_execute.c
--- Zend/zend_execute.c 4 Jun 2009 18:20:42 -0000 1.716.2.12.2.24.2.44
+++ Zend/zend_execute.c 4 Jul 2009 17:20:50 -0000
@@ -506,13 +506,82 @@ static inline int zend_verify_arg_type(z
}
} else if (cur_arg_info->array_type_hint) {
if (!arg) {

•   	return zend_verify_arg_error(zf, arg_num, cur_arg_info, "be an
  

array", "", "none", "" TSRMLS_CC);

•   	return zend_verify_arg_error(zf, arg_num, cur_arg_info, "be of the
  

type ", zend_get_type_by_const(cur_arg_info->array_type_hint), "none",
"" TSRMLS_CC);
}

•   if (Z_TYPE_P(arg) != IS_ARRAY && (Z_TYPE_P(arg) != IS_NULL ||
  

!cur_arg_info->allow_null)) {

•   	return zend_verify_arg_error(zf, arg_num, cur_arg_info, "be an
  

array", "", zend_zval_type_name(arg), "" TSRMLS_CC);

•   /* existing type already matches the hint or forced type */
  

•   if (Z_TYPE_P(arg) == cur_arg_info->array_type_hint || Z_TYPE_P(arg)
  

== (cur_arg_info->array_type_hint ^ (1<<7))) {

•   	return 1;
  

•   }
  

•   /* `NULL` type give, check if parameter is optional */
  

I cant parse this comment.

•   	case IS_NUMERIC:
  

•   		switch (Z_TYPE_P(arg)) {
  

•   			case IS_STRING:
  

•   				if (is_numeric_string(Z_STRVAL_P(arg), Z_STRLEN_P(arg), NULL, NULL, 0)) {
  

•   					return 1;
  

•   				} else {
  

•   					goto type_error;
  

•   				}
  

•   				break;
  

•   			case IS_BOOL:
  

•   			case IS_LONG:
  

•   			case IS_DOUBLE:
  

•   				return 1;
  

•   			default:
  

•   				goto type_error;
  

•   		}
  

•   		break;
  

I dont think bool should be in "numeric".

Index: Zend/zend.h

RCS file: /repository/ZendEngine2/zend.h,v
retrieving revision 1.293.2.11.2.9.2.37
diff -u -p -a -d -u -r1.293.2.11.2.9.2.37 zend.h
--- Zend/zend.h 17 Jun 2009 08:55:23 -0000 1.293.2.11.2.9.2.37
+++ Zend/zend.h 4 Jul 2009 17:20:50 -0000
@@ -536,6 +536,16 @@ typedef int (zend_write_func_t)(const c
+/ used for forcing method/function parameter type */
+#define FORCE_BOOL (IS_BOOL | (1<<7))
+#define FORCE_STRING (IS_STRING | (1<<7))
+#define FORCE_LONG (IS_LONG | (1<<7))
+#define FORCE_DOUBLE (IS_DOUBLE | (1<<7))
+#define FORCE_ARRAY (IS_ARRAY | (1<<7))

Can we have a macro for 1 << 7? It 's used in quite a few places.

Index: Zend/zend_language_parser.y

RCS file: /repository/ZendEngine2/zend_language_parser.y,v
retrieving revision 1.160.2.4.2.8.2.35
diff -u -p -a -d -u -r1.160.2.4.2.8.2.35 zend_language_parser.y
--- Zend/zend_language_parser.y 26 Mar 2009 12:37:17 -0000 1.160.2.4.2.8.2.35
+++ Zend/zend_language_parser.y 4 Jul 2009 17:20:50 -0000
@@ -128,6 +128,14 @@
%token T_DOUBLE_ARROW
%token T_LIST
%token T_ARRAY
+%token T_BOOL_HINT
+%token T_STRING_HINT
+%token T_INT_HINT
+%token T_DOUBLE_HINT
+%token T_RESOURCE_HINT
+%token T_NUMERIC_HINT
+%token T_SCALAR_HINT
+%token T_OBJECT_HINT
%token T_CLASS_C
%token T_METHOD_C
%token T_FUNC_C

Can you use T_BOOL_CHECK etc instead of T_BOOL_HINT?

@@ -661,10 +682,10 @@ lexical_vars:
lexical_var_list:

•   lexical_var_list ',' `T_VARIABLE` 		{
  

zend_do_fetch_lexical_variable(&$3, 0 TSRMLS_CC); }

• | lexical_var_list ',' '&' T_VARIABLE {
  zend_do_fetch_lexical_variable(&$4, 1 TSRMLS_CC); }
• | T_VARIABLE { zend_do_fetch_lexical_variable(&$1, 0 TSRMLS_CC); }
• | '&' T_VARIABLE { zend_do_fetch_lexical_variable(&$2, 1 TSRMLS_CC); }

•   lexical_var_list ',' `T_VARIABLE` 	{
  

zend_do_fetch_lexical_variable(&$3, 0 TSRMLS_CC); }

• | lexical_var_list ',' '&' T_VARIABLE {
  zend_do_fetch_lexical_variable(&$4, 1 TSRMLS_CC); }
• | T_VARIABLE { zend_do_fetch_lexical_variable(&$1, 0 TSRMLS_CC); }
• | '&' T_VARIABLE { zend_do_fetch_lexical_variable(&$2, 1 TSRMLS_CC); }
  ;

I cant see what was changed here?

Index: Zend/zend_language_scanner.l

RCS file: /repository/ZendEngine2/zend_language_scanner.l,v
retrieving revision 1.131.2.11.2.13.2.40
diff -u -p -a -d -u -r1.131.2.11.2.13.2.40 zend_language_scanner.l
--- Zend/zend_language_scanner.l 5 May 2009 01:35:44 -0000 1.131.2.11.2.13.2.40
+++ Zend/zend_language_scanner.l 4 Jul 2009 17:20:50 -0000
@@ -1158,6 +1158,38 @@ NEWLINE ("\r"|"\n"|"\r\n")
return T_ARRAY;
}

+<ST_IN_SCRIPTING>("bool"|"boolean") {

• return T_BOOL_HINT;
  +}

+<ST_IN_SCRIPTING>("string"|"binary"|"unicode") {

• return T_STRING_HINT;
  +}

Someone asked on your last patch about that "unicode", with relation
to 5.3. I think it might be a nice idea for forward compatability, so
no objections, but I wanted to ask your plan for 5.3 with this.

+<ST_IN_SCRIPTING>"object" {

• return T_OBJECT_HINT;
  +}

Great.

There is a good argument for allowing "mixed", and a tiny argument for
allowing "unset"/"null". It would be great if you could add these. I
think that "callback" would be too hard, but if anyone comes up with
an easy way, that would be cool too.

Thanks for all your work on this,
Paul

--
Paul Biggar
paul.biggar@gmail.com