Stefan, > Knut, you were talking about a > > > Let's now consider a different usecase. You again have one module > > declaring the service point, a second module with a final > > (non-overridable) default implementation and a third module providing > > final default implementation. This is contradictory for me. >
I think we don't agree on what we mean by default. The way I see it the default implementation is provided by the same developer(s) who specified the service point. This default implementation can either be overridable (i.e. non-final) or non-overridable (i.e. final). Thus I was talking about a final default implementation. Makes sense? > I just see two terms, which have the following equivalent > - final <=> type == override (from my first proposal) > - non-final <=> type == default (from my first proposal) > I don't quite agree. Does not an override only make sense in the presence of a default? Then how does one declare the default implementation as non-overridable? > Having two implementations A and B for a service point and both > are given, the following should be true: > > impl A final non-final > impl B > final error B wins > non-final A wins error > > In the case that there is just one implementation give, it will > �win� independent on the value of the final attribute. > I certainly agree with this. Selecting the "correct" implementation is trivial, but there is no way for HiveMind to know which implementation was the intended default. Thus it would be difficult to log a meaningful warning. The best HiveMind could do is to guess that the implementation in the same module as the service point (if there is one) is the default. --knut --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
