Support for Group Use Statements

[poldridge]

Added support for group use statements to the TokenParser

http://php.net/manual/en/language.namespaces.importing.php#language.namespaces.importing.group

[guilhermeblanco]

I remembered why I didn't merge this patch before. I need to check against zend_language_parser.y to verify the potential acceptance of:

use Foo\{Bar, Woo}, Bar\{Fuzz, Lala};

If this is not accepted, it's actually a bug in the language grammar, because this is supported:

use Foo\Bar, Foo\Woo;

And I'd have to provide a patch to PHP, which would further require an update in this patch.

[blowski]

@guilhermeblanco It's a good point, and no it doesn't work. The original RFC doesn't mention it.

[tristanbes]

ping, that prevent other libraries using doctrine/annotations to be compliant with use group features :(

What's missing inside this PR so it gets merged ?

[poldridge]

If PHP's grammar is modified to accept: use Foo\{Bar, Woo}, Bar\{Fuzz, Lala}; then replace continue; with $groupRoot = $class = $alias = '';

[poldridge]

Also read the next token and handle it (if it's a comma, skip over it and continue parsing, otherwise it is a semicolon or invalid PHP, and we're done):

if ( $this->next() == ',' ) {
    continue;
} else {
    break;
}

[marcioAlmada]

So, this PR was opened 10 months ago. What's preventing it from getting merged?

The claims the new syntax is "too hard to parse" is not sustainable, the patch looks very simple. It's not as simple as a regular expression, but so many aspects of PHP can't be parsed with regex. This is not the best reasoning when we have libraries like PhpParser and manually parsing a list inside a block is not really a challenge.

The DocParser.php itself has ~1,138 lines of code handling many kinds of syntax edge cases, adding two else ifs on TokenParser won't make any substantial increase in complexity here.

If this is not accepted, it's actually a bug in the language grammar, because this is supported:
use Foo\Bar, Foo\Woo;
And I'd have to provide a patch to PHP, which would further require an update in this patch.

@guilhermeblanco this feels 100% opinion based to me. It also sounds a bit authoritative to consider you have to go fix the language first before merging a PR. It's probably not the intention, but that's the impression it might yield.

Think collectively, the language feature wasn't merged in core by a single person the cowboy way - it was discussed, reviewed, improved, voted, released.

PS: I apologize in advance in case the long wait is happening purely due to lack of availability from maintainers, we all have tons of things to do.

[Ocramius]

LGTM. Merging and preparing 1.3.0!

Thanks @poldridge!

@marcioAlmada yes, it was mostly lack of time delaying merges/reviews, sorry.