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 <felipe...@gmail.com> wrote:

> Hi,
>
> 2010/5/20 Derick Rethans <der...@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
>

Reply via email to