Uploaded image for project: 'phpBB3'
  1. phpBB3
  2. PHPBB3-10175

Class loader cannot find a/b_foo.php when a/b/bar.php exists

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.0-dev
    • Fix Version/s: 3.1.0-b1
    • Component/s: None
    • Labels:
      None

      Description

      The situation of having both a/b_foo.php and a/b/bar.php happens during refactoring when some of the classes have been moved under a/b and some not.

      The current behavior is not user friendly - php says class is not found where it was found just fine in the previous version of the tree and the class has not changed.

      Assuming we own phpbb_ namespace it may be ok to always try searching for a/b_foo.php. Otherwise maybe define a constant in test suite, if it is defined do the second loading pass and print a warning if any files are found there.

        Activity

        Hide
        naderman Nils Adermann added a comment -

        This was intentionally not done to enforce a proper structuring of files. The autoloading RFC defines this quite clearly. I'm ok with searching for the other file and printing a warning in debug mode / during testing. But I don't want to alter the regular loading behaviour.

        Show
        naderman Nils Adermann added a comment - This was intentionally not done to enforce a proper structuring of files. The autoloading RFC defines this quite clearly. I'm ok with searching for the other file and printing a warning in debug mode / during testing. But I don't want to alter the regular loading behaviour.
        Hide
        Oleg Oleg [X] (Inactive) added a comment - - edited

        I think that would be fine. We can spam notices or somesuch in such cases.

        (Printing a notice and not loading the file, that is.)

        Show
        Oleg Oleg [X] (Inactive) added a comment - - edited I think that would be fine. We can spam notices or somesuch in such cases. (Printing a notice and not loading the file, that is.)
        Hide
        Oleg Oleg [X] (Inactive) added a comment -

        This should be addressed by the coding guidelines.

        Show
        Oleg Oleg [X] (Inactive) added a comment - This should be addressed by the coding guidelines.
        Hide
        nickvergessen Joas Schilling added a comment -

        Namespaces

        Show
        nickvergessen Joas Schilling added a comment - Namespaces

          People

          • Assignee:
            nickvergessen Joas Schilling
            Reporter:
            Oleg Oleg [X] (Inactive)
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development