Lee C.

I like the idea of an `@optional()` decorator. My concern with it is that it can create some odd behaviors where a service can have behavior that is different in...

I have always been pretty leery of this feature. I get that it might be useful for testing, but I fear that it would create situations where an object can...

Alright, I think we can accept this PR - please update the readme, and I'll accept it and push out a new version this week. You may need to rebase...

Hmm, interesting. Let me see if I understand this correctly - you're looking to do something like: ```typescript const cmdHandler1 = container.resolve('CommandHandlerDecorated1'); // returns the moral equivalent of new CommandHandlerDecorator(container.resolve('CommandHandlerIml1'))...

How are those cmdHandlers used? If they are resolved as constructor params elsewhere, there is a way to do it (I think), by using the `@injectWithTransform()` decorator. So you might...

Yeah, this has come up a time or two. Both Inversify and Angular implement it as well. I have been reticent to follow suit, because one thing I have always...

@avin-kavish , what is the scenario you have that needs the Optional decorator? I haven't seen the need for it yet, but I do see that Angular has it, and...

That's an interesting idea - it's possible (probably) to change the `resolve()` API to be `resolve(token, ...args)` or something like that. Sort of like `autoInjectable`. I'd definitely look at a...

I think that `@autoInjectable()` allows for this kind of behavior (so you could do `new OrchestrationService(runtimeParam)`), but it wouldn't work with `container.resolve()`.

I recall we tried to implement this once before, but we found a bug where we couldn't prevent it from actually instantiating the abstract class (!) at runtime. Maybe this...