Recursive resolve based on aliases

[sagikazarmark]

It would be a good feature to be able to resolve aliases which are also defined as aliases in the manager.

So AliasedClass->OneMoreAliasedClass->RealClass could work.

Real life example:
Fuel v1 legacy support

Namespace\OldClassName->New\Name\Space\NewClassName
Namespace -> ''

This way OldClassName is available from the global namespace.

Temporary workaround is to use as many managers as the required levels, but that is ugly.

[sagikazarmark]

What do you think about this?

[emlynwest]

Not sure about this, I can see some real bad debugging headaches that could be caused because of this.

[WanWizard]

The reason this package exists is mainly to allow for class replacement when you have something that does not support the DiC (i.e. it does new \Some\Classname) and you want to replace that class with another one.

One if the issues Frank didn't solve was that you can't have the new class extend, because once the original class is loaded, the autoloader doesn't kick in anymore, so you can no longer intervene on a new statement. That is the only downside to aliassing.

Also, as I understand, the "new" DiC no longer does resolving? Because everything that is DiC aware should use the DiC to create instances, which means you can use the DiC to alias a class by injecting it's replacement.

Either way, the functionality to overload and extend any framework class MUST still be present in v2, it's one of the trademarks of FuelPHP, and makes modifications a helluva lot more simple than some other frameworks...

[sagikazarmark]

The whole point of dependency injection is that dependencies are loosely coupled, you can replace them with each other.

Also, you can overwrite aliases in the container as well.