Is there an actual use-case to define the bundle path based on constructor arguments? I don't see any reason to do that.

What about making the method static? Won't that be an easy solution?

@wouterj I don't see any reason to use the constructor args inside the method, but in this case it leads to a fatal error.
Making the method static wouldeasily solve the issue.

EDIT

@wouterj Making the method static gives unexpected side effects as the method uses$reflected->getFilename() as default path and the baseBundle is abstract.

@wouterj the use case is see is to have a "virtual" bundle class that you can add multiple times, specifying the path in the constructor.

@jvasseur In case of setting the path ingetPath depending on constructor args, callgetPath from an instance without constructor would result in the default value (that isdirname($reflected->getFilename()), called bySymfony\Component\HttpKernel\Bundle\Bundle#getPath), or at worstnull.

In case ofgetPath returningnull, the value would be the default too (dirname($reflection->getFilename()) called fromFrameworkExtension#getBundlePath()).

ATM I see a real gain into use the bundle#getPath if available (it will for most bundles), and a real loss if we don't try to use it at all.
Plus, I never saw a bundle that make such logic in itsgetPath (maybe you have an example?).

@chalasr the example i had in mind ishttps://github.com/WouterJ/Bundleless/blob/master/VirtualBundle.php

The problem with creating a bundle withnewInstanceWithoutConstructor is that you don't get a properly instantiated class that could error in the getPath method (for example calling a method on one of its properties).

@jvasseur As the properties are declared but not set (constructor not called), callinggetPath of the example you given would returnnull, and so, because of the condition in the return statement ofFrameworkExtension#getBundlePath, the reflection file directory would be used (i.e.return $getPathReflection->invoke($reflectionInstance) ?: dirname($reflection->getFilename());).

As I understand, you're right, this fixes the issue for most cases but not for this particular (where it would behave as actually), but, while members are properly declared, I don't see how it could lead to errors?

@chalasr It could lead to errors if you do something like this

class Bundle{publicfunction__construct($someProperty)    {$this->someProperty =$someProperty;    }publicfunctiongetPath()    {return$this->someProperty->someMethod();    }}

As said, the proposed fix would cover most of cases (all bundles classes that don't use any constructor argument into thegetPath method). Also it removes duplicated code (getting the reflection file directory was repeated in each method before) and finally, I don't see any other alternative that doesn't involve to add/update/move lots of code (and give BC breaks).

I close this simply because it doesn't solve the problem entirely. Cover it partially would not be a good thing. Hope we soon find a real solution for this blocking issue.