On 2014-07-25, 4:01 PM, Kris wrote:
Hi Sohail,
Definitely interested and will send more comments and questions in a few days Thank you for the interest in the library and looking forward for your comments and questions.
Immediately though: is it possible to separately compile modules and/or the configuration? Yea, it is possible, IMHO the easiest way will be to take advantage of type erasure here, but Pimpl idiom might be - with a bit of effort - achieved as well. So, let's say we want to create application - app - using DI and configuration specified in module - cpp file.
[snip example] So that example is fine when it comes to a single type, but I have hundreds of types that are separately compiled. Creating an injector for each type is cumbersome. Is there a way you can come up with a solution that is generic? I know you suggested type lists but that is too much of a burden.
You linked to my library and one of the insights you have made in yours is that 99.999999999% of the time, the types are actually decided at compile-time whereas in mine, it is always at runtime > (yuck). So good job on that. Thank you, that was one of my main goals whilst designing the library - "Prefer compile- and link-time errors to run-time errors".
In my library, there was only one case I cared about that may not be caught at compile-time: the (lack of) concrete implementation in a base class. I haven't bothered to fix it because the error happens immediately at runtime and the exception thrown tells you what to do. Other than that, I don't recall a single run-time issue beyond this (threading issues aside), but what I was referring to regarding your compile-time bit was that the way you've written it, you can demand an implementation for a base class, which is pretty cool to me. If there was some way to marry your static checking with the convenience of separately compiling the bindings without having to do it for each individual type, I'd switch to your library in a heartbeat! Sohail