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]
