Yes, and I am still a lttle bit confused.
I think there are currently at least three terms used in our discussion: - final - non-final - default
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 just see two terms, which have the following equivalent - final <=> type == override (from my first proposal) - non-final <=> type == default (from my first proposal)
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.
Maybe it is too late for me now. I need some sleep :-) Good night!
Knut Wannheden wrote:
Stefan,
Let's consider the usecase you described in an earlier message. If I understood it correctly it defined the service point in one module, a default implementation in a second module and an override implementation in a third module. How would you express this using the
Yes!
'final' attribute only? You could certainly mark the default implementation as non-final and the overriding implementation as final.
Yes!
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
Hmm, final and default are contradictory. An implementation can either be final (equivalent to type == �override�) or non-final (equivalent to type == �default�) i.e. it is overridable.
a non-final implementation. The third module really makes an illegal contribution, as the default implementation is final.
However, to HiveMind these two cases look equivalent. It will indeed in both cases use the correct implementation, but it won't be able to print meaningful error messages. Should it log a warning in both cases and let the user / developer interpret?
I suppose you're confused since your originally suggested solution didn't expose this problem.
--knut
On 4/25/05, Liebig, Stefan <[EMAIL PROTECTED]> wrote:
Knut,
I do not see the problem. Maybe my misunderstanding is caused by a to shallow view on hivemind internals!
If an implementation is considered as final, isn�t it irrelevant whether it has been explicitly made final or by a default mechanism? Why do you emphasize this �another module�? Shouldn�t it be independent on how many modules are involved? What do you mean with �illegal�?
-----Original Message----- From: Knut Wannheden [mailto:[EMAIL PROTECTED] Sent: Mon 25.04.2005 14:37 To: [email protected] Subject: Re: Again: Overridable services
I think throwing an error is the only reasonable thing HiveMind can do.
However, I think there is still a problem with this single attribute approach: How will HiveMind know which implementation to choose? There is no way to differentiate between these two cases:
- there is a final implementation to be considered as the default and an illegal non-final implementation in another module. - there is a non-final default implementation and a final implementation, intended as override, contributed by another module.
Thus, we do need a second attribute like the 'type' attribute suggested by Stefan. (Alternatively there could be something like a 'modifiers' attribute. E.g. modifiers="default, overridable".)
In any case I think none of this should be declared on the <service-point> element.
--knut
On 4/25/05, James Carman <[EMAIL PROTECTED]> wrote:
> > What happens if there are two non-final implementations? Do we throw an
> error?
> > > -----Original Message-----
> From: Liebig, Stefan [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 25, 2005 7:16 AM
> To: [email protected]
> Subject: AW: Again: Overridable services
>
> > > Knut,
> > I understand your concerns regarding compatibilty but HM 1.1 is sitll in
> alpha!
> I wouldn�t have a guilty conscience about changing the behavour regarding
> this.
> > We should avoid having the �final� in <create-instance> and
> <invoke-factory>,
> because they describe �how� to build a service and the �final� is not a
> �how�.
> I think that the implementation element would be the best place for the
> final
> attribute. Or?
> > Maybe we should get some other opinions?!
> > However, if HM 1.1 compatibility regarding this topic is so important, I
> could live with it.
> "Sealing" a service, would than require to have a �non-inlined� �final�
> implementation, right?
> > > ________________________________
> Von: Knut Wannheden [mailto:[EMAIL PROTECTED]
> Gesendet: Mo 25.04.2005 12:09
> An: [email protected]
> Betreff: Re: Again: Overridable services
>
> > >
> Stefan,
>
> On 4/25/05, Liebig, Stefan <[EMAIL PROTECTED]> wrote:
> >
> > Yes, your objection is definitly right.
> > > > A service is not �overridable�, this is a property of
> > an implementation. And yes, a �final� attribute would
> > much better fit, since it corresponds nicely with Java.
> > It should also fullfill my requirements, having a service
> > with a default implementation and a possible overriding
> > implementation, independent of any same-module semantics.
> > An �inlined� implementation could also be regarded as �final�.
> > If someone wants to have the implementation �overridable�
> > than it should not be �inlined�. With that it would be
> > sufficent to have the �final� attribute within the
> > implementation element.
> > An open question for me is: what should the default value
> > of �final� be?
> > If the default would be �true�, than it would be HM 1.0
> > compatibel - with a �false� default value it would be more
> > like Java. Hmm!
> > >
> As you say, in HiveMind 1.0 a service implementation is always
> "final". In HiveMind 1.1 however, an "inlined" implementation is
> non-final whereas implementations defined using <implementation> are
> final.
>
> IMO inlined implementations should be non-final to remain compatible
> with the current semantics in HiveMind 1.1. And implementation
> provided by <implementation> elements should by default be final.
> Again, that would be how it currently works in HiveMind 1.1.
>
> The following conflicts need to be checked:
>
> - More than one final implementations for any given service.
> - More than one non-final implementations for any given service.
>
> Does this sound like the way to go or would it make more sense to move
> the 'final' attribute to <create-instance> and <invoke-factory>?
>
> --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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
