AW: Again: Overridable services

[Liebig, Stefan]

Title: Re: Again: Overridable services

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: hivemind-dev@jakarta.apache.org
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]