Leo Simons wrote:
[snip]
The ROLE is part of the PLAY. The Actor performs the Role. The Same Actor (read component) can perform (in a theatrical play) Any Role of the Play. The Actor's interface (in a theatrical play) is his/her experience/training/understanding of Acting, so that the director can issue directives like "be more subtle in the expression of grief" (which I, non-Actor, wouldn't have a clue what that would mean).
I can't see how this is the case with Avalon Roles. Is the PLAY restricted to a single interface and a single Role? Probably not. Then if a bunch of interfaces makes the Play, then I can't swap the actors to play the different roles. In fact, it is like saying one particular actor can only play one type of Roles.
yep.
But then, someone will say, a component can implement many different interfaces and by that play many roles
yep, but that's a bad idea. A component should do one thing and do it well.
I've had the use case for a component with more than one work interface and I support the idea of enabling their use... Example:
public interface TimeProvider {
Date getTime();
}public interface MutableTimeProvider extends TimeProvider {
void setTime(Date time);
}The reason here is that the two work interfaces are very closely related, but nevertheless they are two different interfaces and it would be undesirable to merge the two interfaces. My current workaround (with Fortress) is to separate the interfaces and to use DelegatingTimeProvider as the TimeProvider implementation:
public interface TimeProvider {
final static String ROLE = TimeProvider.class.getName();
Date getTime();
}public interface MutableTimeProvider {
final static String ROLE = MutableTimeProvider.class.getName();
void setTime(Date time);
}public class DelegatingTimeProvider implements TimeProvider, Serviceable {
private MutableTimeProvider timeProvider; public Date getTime() {
return this.timeProvider.getTime();
}public void service(ServiceManager sm) throws ServiceException {
this.timeProvider = (MutableTimeProvider) sm.lookup(MutableTimeProvider.ROLE);
}
}
But this is not very elegant and requires the component developer to always write a delegating implementation whenever he/she wants to achieve this effect. And the whole issue becomes many magnitudes more complex when we increase the complexity of the inheritance hierarchy just a bit.
So my suggestion would be: allow simple things be simple and complex things possible (similar to the PERL slogan). Leo has a point about the simplicity and enforceability of the ROLE strings. Alex also has a point about the extended capabilities of the meta solution. So how about we just document both approaches and highlight pro's and con's of both? So the recommended approach depends directly on the container where we plan to deploy the component. And if we need cross-container compatibility, just add in both: ROLEs and meta-data.
(and it would be about time to meta-enable fortress, but that is entirely separate thread...)
Rgds, Neeme
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
