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

Felipe, Wouldn't the simpler change be to allow use of no spaces between scalar hint and a variable? Basically change + to a *? On Fri, May 21, 2010 at 9:07 PM, Felipe Pena <felipensp@gmail.com> wrote: > 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 >