Berin Loritsch wrote:
Stephen McConnell wrote:
This one. It is much easier to mark an interface with a flag than to rely on the fact that I have a memory like a seive.
LOL :-)
Know what you mean. However, it's problamatic in that it locks you into a model where the interface can only be a work interface and cannot be applied as a internal interface. I've thought about the same approach with respect to lifecycle stages in Merlin and reached the conclusion that its too restrictive - ended up focussing on explicity declaring the published services, lifecycle extensions, etc. in the component. But keep in mind that what I have been doing is still real early.
Who said you can't have it both ways? I have seen nothing to restrict us to forcing only one way on the attribute declarations.
If you use the same tag to declare that an interface is a service, and to declare that a class is exposting a service, then you lose the ability to verify placement relative to context. I agree that it would be feasible to have both, but they should be different statements - for example.:
@avalon:service.defintion // marks an interface as a service
@avalon:service org.apache.playground.Demo // this component class exports the Demo interface
This enables you to verify that a tag is within a valid context - i.e. avalon:service.defintion would be valid in the header of an interface whereas avalon:service would be valid i the header of a class.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
