Re: svn: /php/php-src/trunk/ NEWS Zend/tests/array_type_hint_001.phpt Zend/tests/hint/param_type_hint_001.phpt
Zend/tests/hint/param_type_hint_002.phpt Zend/tests/hint/param_type_hint_003.phpt Zend/tests/hint/param_type_hint_004.phpt Zend/t

Hi, 2010/5/20 Derick Rethans <derick@php.net> > derick Thu, 20 May 2010 19:18:35 +0000 > Revision: > http://svn.php.net/viewvc?view=revision&revision=299534 > > Log: > - Added scalar typehinting. > > Changed paths: > <changed paths exceeded maximum size> > > > Any reason to not do the same as array is treated nowadays? e.g. <ST_IN_SCRIPTING>"object" { return T_OBJECT; } I'm asking because the type names are surely intended to be reserved words from now. Using: <ST_IN_SCRIPTING>("string"|"binary"){TABS_AND_SPACES}[ \t&]+"$" { is confusing because we might to create the String/binary class in PHP and when trying to use it as type-hint it will ask for the php type, not the class... obviously. Which represent a BC independentely of 'string' not being a reserved word. (If was this the reason for the token rules just to match arguments) And just to informe, the source as is, we have the following issues: foo(string$var) -> expect an string class instance foo(string $var) -> expect a php string type It need be like: ("string"|"binary"){WHITESPACE}*("&"{WHITESPACE}*)?"$", but I think it shouldn't be a argument specific rule, but the same as T_ARRAY is. Patch to make string, real, binary, etc... reserved words: http://dpaste.org/00Le/raw/ If no objections, I'll commit it, alright? :) -- Regards, Felipe Pena