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 'final' attribute only? You could certainly mark the default implementation as non-final and the overriding implementation as final.
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 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]
