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

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

Patch to make string, real, binary, etc... reserved words:

If no objections, I'll commit it, alright? :)

Felipe Pena

Reply via email to