Just when you guys have gotten on the same page, let me inject another variable.

Suppose you have a service with several implementations available. Let's say that one is the default one, (which is not final), and there are two others. How do you choose which one to use?

Before you say "just don't do that", suppose that each of these other two belongs to a different module, and that you require other services from both modules.

I suggest that there should be a way to explicitly select one of the available implementations via symbols or some other built-in configuration point. I don't know what the precise solution should be, but I think we need one.

Luke

Liebig, Stefan wrote:

Knut,
now I think I got what you mean!
You are using �default� (either �final� or �non-final�) to describe the intention
of the provider/developer of a service. His choices for a service could be:
- default, non-final => this may be overriden
- default, final => this can not be overriden
- default, open (no implementation) => "could someone please implement this!"
While our discussion I dropped this �intention� which I had in mind with
my first proposal (the �overridable� attribute within service-point) and
assumed that final and non-final could be sufficent.
The above intentions could than be expressed as:
- this may be overriden => non-final implementation
- this can not be overriden => final implementation (this is what discomfits you, right?)
Do you have a proposal (without any same-module magic) in mind, which would solve
this problem?


------------------------------------------------------------------------
*Von:* Knut Wannheden [mailto:[EMAIL PROTECTED]
*Gesendet:* Di 26.04.2005 09:21
*An:* [email protected]
*Betreff:* Re: Again: Overridable services

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]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to