[OptimizeUse] Implemented feature optimize use

[pscheit]

Hi there,

this is my first try at the "optimize use" (-statements) from the roadmap.
I had to extend the Namescanner to collect informations about the parent, because I had to differentiate between PhpNames that are in use statements and are just somewhere in the (class-)file. I wasn't quite sure to extend it here, or create another name scanner function or collector.
Thats why I added a parent property to the PhpName and had to adjust the tests.

While contributing some questions came up, that I can't find a guideline for:

• when do i need to prefix get*** for getters an when not? (PhpClass::getDeclaredNamespaceLine vs PhpName::fullyQualifiedName())
• do you write "constant" === $variable like in Symfony or does it matter at all?
• should file and line/line-range in objects of the model domain always be optional in constructor?
• i had to adjust the behat test after creating it, because of the diff @@ @@ notation. Because of this it's a little bit tricky to write expected patches for behat. Is it possible to work around it a little nicer?
• is there a guideline for commit messages? (I think i screwed it up)

Best regards
Philipp

[beberlei]

1. I started with get* but then stopped using that, as it sucks. I didnt change all the occurances yet.
2. Doesnt matter
3. no, this is some unrefactored part as well :(
4. have to take a look at that
5. no

[beberlei]

wrap { please

[pscheit]

this is way to much anchored in my tiping-fingers :) I think that were all non wrapped braces.

To change the constructors to non optional does not look very complicated. And the getters without get, too.

[beberlei]

@pscheit I refactored the Fix Class Names alot today, which makes this PR unmergable due to conflicts, some work needs to be done.

My Idea is, in the new PhpNameOccurance have a $type constant being class, use, namespace, other or something like this. We wouldn't need the parent then anymore. The PhpName stays clean then, you dont need UseStatement anymore and much of the other code simplifies as well.

[pscheit]

allright. That was my first attempt to do this as well. But I thought about multi-line-use statements at the top of the file. And for the optimize use I have to append single line use statements at the end of the use statements. That's why I created the more flexible parent instance. Because the PhpName can be in the multi-line-statement over more than one line.

[beberlei]

@pscheit yes, its true with the multi-line use statements. but the problematic kind would be:

use Foo,
      Bar
;

And this one is undetectable anyways i would suppose and an edge case. Everything else works fine, finding the last use statement and adding a new line.

[pscheit]

Why isn't it detectable? I think PHPParser is providing the start + endline of the multi line statement (even, when the ; is in the next line)
Well okay I'll adjust my PR to your changes then, and we'll see what will blow up :)

[beberlei]

@pscheit starting to realize that i need this information myself for the fix-class-names refactoring, just wait a little longer and you get more and more code to use ;-)

[pscheit]

hehe allright. I would have tried to talk you into using the parent property anyway these days

[beberlei]

@pscheit Merged this into my latest master with the fixes for fix-class-names and integrated the current API with this patch. Its working great. Thanks for the contribution!

[pscheit]

hey, cool that you got managed to merge it in the end. I had no time to have a further look at it, but i planned to do so. Great that its working.