RE: Again: Overridable services

[Liebig, Stefan]

Title: 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]