RE: Again: Overridable services

[James Carman]

Title: Message

The problem is that HiveMind will not know which one is the default in the situation where there is one non-final and one final implementation provided for a given service point.  How does HM know that the non-final one is supposed to be the default and the final one is playing nicely?  Couldn't it actually be the case that the final one was supposed to be the default and the non-final one is not playing nicely?

-----Original Message-----
From: Liebig, Stefan [mailto:[EMAIL PROTECTED]
Sent: Monday, April 25, 2005 9:30 AM
To: hivemind-dev@jakarta.apache.org
Subject: RE: Again: Overridable services

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]