batch reassigning

(In reply to comment #0)
> as far as I know, a declaration of namespace like namespace \NamespaceName is
> wrong because of preceding backslash. This
> declaration is not underlined.

Right PHP will thow: Fatal error: Undefined constant 'NamespaceName'

*** Bug 196039 has been marked as a duplicate of this bug. ***

yeah, it throws an error, but its not wrong.
You could for example declare the constant and no error is thrown anymore.
But it will not work as expected.

So a hint as described in Bug 196039 is the better solution.

(In reply to comment #4)
> yeah, it throws an error, but its not wrong.
> You could for example declare the constant and no error is thrown anymore.
> But it will not work as expected.
> 
> So a hint as described in Bug 196039 is the better solution.

I can't come instantly with scenario in which using constant in such way could be used. :( 

On the other hand, I can see situation in which constant having the same name is defined somewhere else resulting in quite strange and hard to notice bug.

Therefore, your request to mark such case as error sounds as better solution to me.

P.S. Vote for the bug. It's very important since votes are counted when deciding which P3 bugs will be fixed in NB 7.0

yeah, the code "namespace /space;" is really useless, but its valid php, so an error could be irritating.

additionally, "$var = namespace /space;" or better said "$var = namespace/space;" make sense.

For example the code "CONSTANT;" is valid code, too. (and there is no hint, too)

its no easy case we have here, and to show an error seems not right for me, if there is no error.
Its only an unexpected behavior.

(In reply to comment #6)
> yeah, the code "namespace /space;" is really useless, but its valid php, so an
> error could be irritating.
> 
> additionally, "$var = namespace /space;" or better said "$var =
> namespace/space;" make sense.
> 
> For example the code "CONSTANT;" is valid code, too. (and there is no hint,
> too)
> 
> its no easy case we have here, and to show an error seems not right for me, if
> there is no error.
> Its only an unexpected behavior.

I don't mind. Error or hint. The point is to have visual information that something might be wrong.

Whichever way Filip decides to fix it I will not object. :)

The hint is not probably the right solution, because hint is visible only when the caret is on the line. 

From my point of view is problem that this is runtime error and for the parser it is ok. 

I was thinking about creating post parsing warning, that would check the php source and create a warning for such cases.

(In reply to comment #8)
> The hint is not probably the right solution, because hint is visible only when
> the caret is on the line. 
> 
> From my point of view is problem that this is runtime error and for the parser
> it is ok. 
> 
> I was thinking about creating post parsing warning, that would check the php
> source and create a warning for such cases.

I am not sure what kind of warning is post parsing warning, but if it means that if there is constant defined in the project global scope there will be no warning, I could not agree more with you.

namespace \PHP_OS will not create warning since constant \PHP_OS [1] is defined in the global scope. On the other hand if constant MY_NAME_SPACE is not defined in the project global scope, namespace \MY_NAME_SPACE will produce warning. 

[1] I can imagine some smart guy using this brilliant idea to load Windows or Linux version of the application. ;)

*** Bug 207545 has been marked as a duplicate of this bug. ***

I think that this is really not a defect, since it's a syntactically correct. It's a common expression with a namespace name. And as Petr wrote, it's OK for parser and it's recognized as a NamespaceName node in AST...same as other namespace name usages in a file (type hints, class instatiations, etc.), so we can't figure out if it's a "suspicious namespace declaration" or just a common namepsace name usage.

It's a valid enhancement, but with a low priority for me.