rdlowrey / auryn

IoC Dependency Injector
MIT License
722 stars 65 forks source link

Aliasing concrete class #15

Closed Danack closed 11 years ago

Danack commented 11 years ago

I'm not sure if aliasing a concrete class to another concrete class is meant to work or not:

class ConcreteClass1{}

class ConcreteClass2{}

function testAliasingConcreteClasses(){
    $provider = new Auryn\Provider();
    $provider->alias('ConcreteClass1', 'ConcreteClass2');
    $class = $provider->make('ConcreteClass1');
    $this->assertEquals('ConcreteClass2', get_class($class));
}

Expected :ConcreteClass2 Actual :ConcreteClass1

rdlowrey commented 11 years ago

Hmm. I would have expected that to work. I'll look into this and try to fix it tonight.

UPDATE

Actually now that I think about it I remember specifically only applying the aliases for non-concrete names. I don't really see any drawbacks for aliasing concrete class names, though. I'll fix/test/commit/push this along with a couple other things and tag in a little while.

UPDATE 2

This actually has consequences elsewhere. Currently if you define an alias the Provider will throw an exception after instantiating the alias class if it's not an instanceof the original un-aliased type. I don't really see any benefit to the current behavior, though. If you're employing dynamic typing loosening this restriction opens up the ability to do some nifty stuff and if you're working against a typehint PHP will throw if the aliased instance is invalid anyway.

So, in summary, I'm still implementing this change but I just wanted to document the change in behavior.