RE: Again: Overridable services

[James Carman]

Title: Message

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