Hi, > From: Dominique Devienne [mailto:[EMAIL PROTECTED] > > One comment about roles: Roles are fine, but roles are just > strings... If > everything is defined as a component at a low level, then > they can be easily > introspected to find out what interfaces components > implement. For example, > why would I have to say: > > <define classname="a.b.C" name="..." role="selector"/> > > when class a.b.C does implement FileSelector! The role is > implicit thanks to > the type of the class itself. I suspect there will be more > cases where a > role maps directly to a single given interface than to an > arbitrary bean, > which is the only case where a role string needs to be specified!?!? >
Good observation. But in the proposal, roles ARE NOT JUST STRINGS. Roles are interfaces with an optional "adaptor" class. So all what you are saying more or less applies already. I am not too keen about automatic discovery of roles because I do not have a full feeling for it, it could come in the future. > So an AntLib system that forces to spell out (string) roles in an XML > descriptor (which I also prefer over the Manifest) when the > defined class > itself already embeds this info in it own type will be > cumbersome at best. > Remember that data-types have no restriction on implementing anything. Given BC you need to be able to support it. This is why I had to add this concept of Adaptor to a Role, so that we could treat everything in a unified standard way. > --DD > > -----Original Message----- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 23, 2003 10:12 AM > To: [EMAIL PROTECTED] > Subject: Re: antlib > > >> With that, do we really need separate <task> and <data-type> in > >> <antlib> or are they just special cases of roles? > > > > They should be. > > So if they are just roles, why treat them in a different way than > other roles? Why a <task> element? > > <define classname="..." name="..." role="task"/> > > could do the same and be more consistent. I don't have a strong > feeling here, just trying to find my way through the ideas without > having to read the code ;-) > > Maybe something could even be in different roles at the same time? > See available, checksum or uptodate for things that are tasks and > conditions in one. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >