aliases vs definition

[designermonkey]

IMPORTANT: If an injection definition is defined for a parameter covered by an implementation assignment, the definition takes precedence over the implementation.

I have a namespace aliased to a class, and also have defined one of the parameters for a class that requires the namespace in it's constructor, yet I get an error for the namespace requirement: Injection definition required for interface ...

I don't have to define all the parameters for a constructor in a definition though right? I thought I only had to define the ones that needed a specific concrete definition?

[kelunik]

You have to alias interfaces with a concrete implementation, otherwise Auryn won't know which class implementing the interface should be used.

[designermonkey]

I have a namespace aliased to a class

I have.

Even though I have made the alias, when I make a definition for a class that has that namespace in it, it does not use the alias and throws the error.

[kelunik]

You have to alias the interface, not a namespace. Could you show the code you're using?

[designermonkey]

I meant interface, sorry. After pulling the entire application apart, I think it is how I am adding the aliases that is the issue.

I am very tired with a big project, so apologies for wasting time here. I will double check first and close this if it is my code.

[rdlowrey]

No worries. It's best to always post code if possible -- it generally makes it easier for other folks to quickly diagnose any issues :)

[designermonkey]

I know, problem is the complexity of this app; Config files for definitions, injector bootstrapper mapping array values to injector functions, etc etc.

Today's exercise: Simplify.

Thanks though guys.

[designermonkey]

Aha!

So, it turns out that I have been defining the parent class, as I have lots of classes in an ADR pattern that use the same constructor from the parent.

Do I have to define each one separately?

[rdlowrey]

Yes, the definitions are not transferred down to child classes. While this would be a nice feature it would be prohibitively slow in practice because we'd have to traverse the full inheritance tree using reflection. It's a lot of overhead. It might be something we could do in the future but even then it would probably only be an option setting because it's a cost that would be incurred for every single instantiation whether necessary or not.

[designermonkey]

I decided to refactor and abstract out the problem areas, so instead of having many classes relying on the parent constructor, I had the parent constructor accept a single class instead that had all the definitions inside it's own constructor instead. It's a mapper of data repositories, and actually much more useable in practice.

Thinking about it, I wouldn't want to request that this is done as like you say, there would be a lot of overhead and possible assumptions too.

Thanks for your time, and the most useful package I've found yet :D

[cspray]

FWIW I requested similar functionality and came to the same conclusion that @designermonkey did. I don't think this should be added to the library.