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]
