inherited providers for qualified dependencies not found by compiler when checking for completeness

[adennie]

If a base module class has a provider method for a qualified dependency, the derived module class is flagged with a compiler error if it has an entry point that depends on the qualified dependency. This gist shows the problem: https://gist.github.com/adennie/5199473.

The workaround is to override the qualified provider in the derived class and delegate to the base class' provider.

This problem doesn't arise if the provider and the dependency don't use qualifiers.

[swankjesse]

Hmmm . . . I'm tempted to forbid subclassing modules altogether. Composition instead of inheritance, right?

[cgruber]

I'm inclined as well, though there are some legacy migration cases we're
encountering where it's saving a lot of work, but that's a weird case.
Off by default would certainly be my preference, and explicitly not
allowing for any module-ness out of the parents (like @provides, @module
declarations, etc.) People keep wanting to use Modules as very fancy
parts of their infrastructure and core code, rather than as
specifications of their system's structure, period.

[tbroyer]

We'll want to do a few changes to the code then:

• Remove the TODO in ProvidesProcessor
• Remove support for subclassing in ReflectiveModuleAdapter

[jclouds]

+1 personally I'll have short term work when subclassing is removed, but I
can see the benefits.

On Sunday, March 24, 2013, Christian Edward Gruber wrote:

I'm inclined as well, though there are some legacy migration cases we're
encountering where it's saving a lot of work, but that's a weird case.
Off by default would certainly be my preference, and explicitly not
allowing for any module-ness out of the parents (like @provides, @module
declarations, etc.) People keep wanting to use Modules as very fancy
parts of their infrastructure and core code, rather than as
specifications of their system's structure, period.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/188#issuecomment-15352857
.