Does not really look right to me.

It only works because the token value is not taken into account in the @EventEmitter case - it works as long as the token has a value.

May be a better way to solve this would be to add an implicitType property to DependencyAnntotaion (or a derived class) that would be initialized to Function for EventEmitter ?

Right, I was also uneasy about this approach. @vicb what would be the interaction between implicitType and token? Maybe @EventEmitter & co. should simply have token property?

I was thinking about token = ann.implicitType but actually you're right ann.implicitToken would probably be better as it could be anything (w/ or w/o the "implicit" prefix)

Ok. So the only problem I can see that with this we are going to have 2 different "sources" of tokens - either a type annotation or a token from the @EventEmitter and we will need to somehow deal with a situation where both parties differ in an opinion on what a token should be...

As of today the implicitToken would only be used to give token whatever value for the else branch no to be taken - we actually don't care about the actual value.

Maybe we could have a special annotation class DependencyAnnotationNoToken extends DependencyAnnotation that would avoid the branch, ie else if (!noToken) (noToken would be set to true if any annotation is instanceof DependencyAnnotationNoToken) ?

You can inject EventEmitter without specifying the type annotation as follows:

@Inject(Function) @EventEmitter('onChange') eventEmitter

But it is not very clean.

I think that what we should do.

We can change the DependencyAnnotation type to look like this:

class DependencyAnnotation {
  //...
  get token(){return null}
  //...
}

So DependencyAnnotation must have the token getter. And if it returns a non-blank token, we use it.

Moreover, we can potentially make Inject, InjectLazy, and InjectAsync extend DependencyAnnotation. Currently, all of them have this interface:

interface Inject{
  get token()
}

So it will work.

Finally, what happens if you have more than one annotation providing the token applied to the same parameter? Currently, the last one wins. So we can keep this behavior.

@vsavkin perfect, understood. Will update the PR accordingly.

add some inline comments