The original plan for handling duplicate provisions has a major flaw. So major, that currently, mounted provisions will simply break things.
Let's say we have two features featureA and featureB, that both provide a foo. Currently, the compiler will report an error and require the user to override the provision in the configuration, something like this:
@Provision
public Foo foo() {
return featureA().foo();
}
However, in the generated code, the mounted provisions of both featureA() and featureB() will be overridden to use the provision from the configuration → we get an infinite recursion.
Introduce some attributes to the mount annotation:
@Provision.Mount(select="..." /*, reject="..." -- don't add this, see #104*/)
public abstract Foo foo();
This gives the compiler all the information it needs to correctly generate the code. It's also more visible what's actually going on.
The original plan for handling duplicate provisions has a major flaw. So major, that currently, mounted provisions will simply break things.
Let's say we have two features
featureA
andfeatureB
, that both provide afoo
. Currently, the compiler will report an error and require the user to override the provision in the configuration, something like this:However, in the generated code, the mounted provisions of both featureA() and featureB() will be overridden to use the provision from the configuration → we get an infinite recursion.
Introduce some attributes to the mount annotation:
This gives the compiler all the information it needs to correctly generate the code. It's also more visible what's actually going on.
Related to #104