This seems like a good argument to me. It's functionally identical and has better backward compatibility.
I'm just saying. . . _____ From: Liebig, Stefan [mailto:[EMAIL PROTECTED] Sent: Thursday, February 24, 2005 11:03 PM To: [email protected] Cc: [EMAIL PROTECTED] Subject: AW: Overridable service implementations Knut, unfortunatelly your answer did not went into the email system at work. I read your answer in gmane.org at home. However, the solution implemented now in Hivemind is still "tricky". It breaks compatibility between 1.0 and 1.1., because making a service final or overridable is made implicitly by the way you write the service point definition and service implementation: <!-- Overridable service with default implementation --> <service-point id="Command" interface="de.test.IMyInterface"> <create-instance class="de.test.MyImplOne"/> </service-point> <!-- Final service --> <service-point id="Command" interface="de.test.IMyInterface"/> <implementation service-id="Command"> <create-instance class="de.test.MyImplOne"/> </implementation> Both ways above were in 1.0 identical. Now they are different. A problem can arise (and it did) when in a another hivemodule someone also made by mistake an implementation of this service and ignored the warning. In 1.0 his implementation was ignored, in 1.1 it will be used! You can not declare a service as final within the service itself. So, you need to provide an non-inlined implementation. But assume depending on how your application is partitioned that you "can" not or don�t want provide the "sealing" implementation in the same module where the service has been declared. Than depending on the order of modules you can get different results. Therefore I would prefer a explicit form in the way I described. Thru the definition of default values you can also make the extension backward compatible and also avoid typing more than you need. Stefan _____ Von: Liebig, Stefan [mailto:[EMAIL PROTECTED] Gesendet: Di 22.02.2005 15:50 An: [email protected] Betreff: Overridable service implementations We have quite often the case that we would like to have a default implementation for a service, which should be overridable by the users of our framework. The possibility to achieve that by using the application/factory defaults is not very obvious and hides this semantic because it can also be used for many other things. Could we not add two attributes to the existing service point/implementation elements to support this? Such as: <service-point id=".." .. overridable="true"/> <implementation service-id=".." type="default"/> <implementation service-id=".." type="override"/> With: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> : not requiered, ( true | false ), default value = false [EMAIL PROTECTED]: not requiered, ( default | override ), default value = default [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> defines whether a service is overridable or not. Default behaviour is like it is today, which is not overridable. [EMAIL PROTECTED] defines whether the implementation is a default implementation or the overriden implementation. Default is �default�, so that the behaviour is as today. An �inlined� implementation is a final (not overridable) implementation if [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> is false. If [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> is true than the �inlined� implementation is a default (overridable) implementation. Possible conflicts (hivemind errors/warnings): [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> == false && [EMAIL PROTECTED] == override more ? Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
<<attachment: winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
