You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A user suggested offer an option to export a linq expression in addition to ExportFactory<T>. The idea would be that calls to Arg.Locate<T>() would be replaced by the container with the proper dependency.
This could allow the developer to make more interesting exports that have runtime logic in them while still maintaining the injection hierarchy.
@ElMaxxi I opened this issue up to track the work for this but now I'm remembering the limitations involved with lambda to expression tree conversions.
Currently there is not support for a number of C# language features including but not limited to statement body. This is a huge limiting factor and for me makes me it not worth implementing.
If MS decides to implement more features for expression trees then this would be cool but right now it doesn't do anything that can't be done using the current configuration methods for Export<T>
I believe that adding such an option, will allow other "gracers" a bit more creativity on the creation of their types. Can't wait to see how it'll turn out :-)
@ipjohnson this looks pretty cool. Is it possible to throw in an IExportLocatorScope to the arguments of the expression? just as is possible with the exportfactory?
@ipjohnson well i didn't mind the Arg, i just thought that having access to the site will let me have access to scope properties to help with the logic. Something enabling, for example, a different logic, if the scope name matches a specific scope.
Activity
ipjohnson commentedon Aug 24, 2017
@ElMaxxi I opened this issue up to track the work for this but now I'm remembering the limitations involved with lambda to expression tree conversions.
Currently there is not support for a number of C# language features including but not limited to statement body. This is a huge limiting factor and for me makes me it not worth implementing.
If MS decides to implement more features for expression trees then this would be cool but right now it doesn't do anything that can't be done using the current configuration methods for
Export<T>ipjohnson commentedon Sep 1, 2017
Thinking about it a bit more it really doesn't add much to implement so I'll include it.
logichaos commentedon Sep 1, 2017
I believe that adding such an option, will allow other "gracers" a bit more creativity on the creation of their types. Can't wait to see how it'll turn out :-)
ipjohnson commentedon Sep 2, 2017
@ElMaxxi What I've added so far is
ExportExpression<T>(Expression<Func<T>> expression)allowing for something likelogichaos commentedon Sep 3, 2017
@ipjohnson this looks pretty cool. Is it possible to throw in an IExportLocatorScope to the arguments of the expression? just as is possible with the exportfactory?
ipjohnson commentedon Sep 3, 2017
@ElMaxxi Something like this
logichaos commentedon Sep 3, 2017
@ipjohnson well i didn't mind the Arg, i just thought that having access to the site will let me have access to scope properties to help with the logic. Something enabling, for example, a different logic, if the scope name matches a specific scope.
ipjohnson commentedon Sep 3, 2017
What if I put in
Arg.Scope()and that gave you access to the scope so you could do something likelogichaos commentedon Sep 3, 2017
That would be totally fine.
I really appreciate your prompt followup on this :-)
More features for issue #113
ipjohnson commentedon Sep 4, 2017
I've added
Arg.Scope()andArg.Context()I also added something that I thought was kind of interesting
Arg.Locate(new { })where you can specify how some dependencies are resolved.Arg.Locate(new { SomeValue = 5 })will use the value 5 for int dependencies named someValue.Here are the tests I've added
ipjohnson commentedon Sep 4, 2017
I've pushed a beta version to test this, let me know if you have any other suggestions.