php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #62042 Fatal error when merging files due to class/function/symbol name collision
Submitted: 2012-05-15 21:05 UTC Modified: 2021-08-08 04:22 UTC
Votes:5
Avg. Score:3.4 ± 2.0
Reproduced:4 of 5 (80.0%)
Same Version:2 (50.0%)
Same OS:3 (75.0%)
From: phplists at stanvassilev dot com Assigned: cmb (profile)
Status: No Feedback Package: Unknown/Other Function
PHP Version: 5.3.13 OS: All
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: phplists at stanvassilev dot com
New email:
PHP Version: OS:

 

 [2012-05-15 21:05 UTC] phplists at stanvassilev dot com
Description:
------------
These two namespaces work as expected when in two separate files, and when 
included together at runtime work as expected as well, but once they're merged 
in the same file they result in a Fatal Error:

namespace Foo {
    class Bar {}
}

namespace Foo {
    use Bar;
}

Fatal error: Cannot use Bar as Bar because the name is already in use.

I understand this behavior was introduced with good intentions, but all it does 
is break working code when files are merged together. The alternative namespace 
construct was introduced specifically to support merging of multiple files 
together without side effects, and this is such a side effect.

Expected result:
----------------
I expect that "use" statements should override default resolutions, and no Fatal 
Error should be produced (the EXACT behavior we have right now when the above is 
spread in two files which are required() at runtime).

Actual result:
--------------
Fatal Error when merging code.

Patches

Pull Requests

Pull requests:

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-03-18 19:17 UTC] joseaugustodearaujonascimento at gmail dot com
The same problem arises when in a two namespace context.

# File: App\N2\Foo.php

namespace App\N2;
use App\N1\Bar;

class Foo
{

}

# File: App\N2\Bar.php
namespace App\N2;

class Bar
{

}

# File: App\N1\Bar.php

namespace App\N1;

class Bar
{

}

Using Bar of App\N1 cause the same problem.

I think that the use in App\N2\Foo.php should only be valid on the App\N2\Foo 
class context and not reflected on the entire 
namespace as the error message suggest.
 [2014-01-20 16:51 UTC] HMWiesinger at liwjatan dot at
IMHO the correct behavior would be to throw a fatal error in all scenarios. Identifiers need to be unique. When declaring the same class in two separate files you get a name conflict as well, so I don't get why you shouldn't get one with namespace aliases either.
 [2014-01-20 17:28 UTC] phplists at stanvassilev dot com
To "HMWiesinger at liwjatan dot at":

Those aren't class names, but local aliases, which are scoped only to a namespace declaration. This is the entire point of namespace aliases, that they're not global.

An alias declared in one namespace block doesn't work in another. So it makes no sense to check for alias uniqueness across namespace blocks at global level or file level, but at namespace block level.

It's a bug.

The correct solution is no fatal errors.
 [2021-07-26 13:53 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-07-26 13:53 UTC] cmb@php.net
For reference: <https://3v4l.org/8iZWh>.

> […] but once they're merged in the same file […]

I don't see much point in doing that; use autoloading and OPcache.
 [2021-08-08 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 13:01:31 2024 UTC