Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RootNamespaceNormalizer: empty namespace is null, not '' #68

Merged
merged 2 commits into from
Nov 26, 2018

Conversation

dg
Copy link
Contributor

@dg dg commented Feb 4, 2017

Otherwise it prepends leading \ to class references inside namespace.

Otherwise it prepends leading `\` to class references inside namespace.
@aik099
Copy link

aik099 commented Feb 4, 2017

Was changed code covered by tests? I wonder why none of tests failed without your change.

@lisachenko
Copy link
Member

I'm not sure, that top-level namespace should be null. Actually, I want to make it \, but we can discuss this.

I like strong typing, so if talk about namespace name, it can be either empty string or \, but not null, because it will violate the return type (in future)

@dg
Copy link
Contributor Author

dg commented Feb 4, 2017

I think test was wrong, ie. test counts with leading \.

When you parse this by Nikic PHP Parser:

namespace { class X {} }

It will generate Namespace_(null, ...) and leading slash will never appear.

RootNamespaceNormalizer generates Namespace_(new FullyQualified(''), ... and then Name::concat() returns leading slashes.

@dg
Copy link
Contributor Author

dg commented Feb 4, 2017

I like strong typing, so if talk about namespace name, it can be either empty string or , but not null, because it will violate the return type (in future)

Me too. It is not about empty string vs null but about object vs null.

@lisachenko
Copy link
Member

Could you please add a broken test? Is it a big issue for you that class name is FQDN with leading slash? Because logically FQDN with leading slash is more correct way to specify a class name. But it can be my personal taste :)

@dg
Copy link
Contributor Author

dg commented Feb 4, 2017

Leading slash or not is not problem, it can be matter of personal taste, the problem is inconsistency. PhpParser never returns leading slash, but RootNamespaceNormalizer makes inconsistency and when you parse this code

<?php 
class X extends Y
{}

some methods (I think Locator is among them) suddenly receives \Y instead of Y.

@lisachenko
Copy link
Member

Could you check #67 (merged into the master branch). Looks like it is related to this issue too.

@lisachenko
Copy link
Member

Unfortunately, there are many checks in the code that verifies that instance of name object is FullyQualified. If we replace it with null for the top-level namespace something can change and can result in broken BC for the external clients.

Copy link
Member

@lisachenko lisachenko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New version of php-parser declares top-level namespace with null, so let's proceed with that.

@scrutinizer-notifier
Copy link

The inspection completed: No new issues

@lisachenko lisachenko merged commit d36faf7 into goaop:master Nov 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

4 participants