On Wed, 20 Feb 2002 19:31, Conor MacNeill wrote:
> Having thought about this a bit more I think, besides the hokiness of
> having to implement a separate interface for every extensible nested
> element I want to support
Why do you think it is "hokey"?
> there are problems when a task supports two
> nested elements with the same underlying type.
>
> For example, consider a task which takes two filesets
> <diff>
> <fromFS .../>
> <toFS .../>
> </diff>
>
> It has methods like this
> addFromFS(Fileset from);
> addToFS(Fileset to);
>
> I cannot have both of these being extensible.
Im not sure why you couldn't just have something like
public void add(Fileset fs)
{
if( null == from ) from = fs;
else if( null == to ) to = fs;
else throw new Exception("Too many FileSets!" );
}
In either case I don't think it is simple for the userto have multiple
extensible elements within the same element. How would they tell when an
instance of one extensible is meant to be used and not an instance of the
other extensible type? Especailly troubliung given that the same name may
exist in each role but represent different classes.
> If we have to have roles, I think they must be based on the class
> supported by the nested element rather than the container.
+1
--
Cheers,
Pete
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
