Peter Donald wrote:
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"?
If I have a method
addFileset(Fileset f)
that should be enough to allow it to be configured with a Fileset or any subclass of fileset. It should work whether Fileset is a class or an interface. I really don't think I should have to implement an interface for each different addXXX method my task supports. That's "hokey" :-)
Not only that, if I don't think ahead, the task will not support extensibility for any elements for which I do not create and implement an appropriate interface. Thats just bad.
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!" ); }
Well that would introduce ordering semantics into the nested elements where today the order of nested elements is unimportant. Further, most addXXX methods can accept multiple instances and accumulate these. This would no longer be possible.
The problem with role based extensibility is that you are trying to determine two independent things from one name. They are the method to call (addfromFS or addToFS) and the actual type of the instance to be passed to the method. With only one piece of info you need to artificially limit the choices.
In either case I don't think it is simple for the userto have multiple extensible elements within the same element.
If <ejbjar> were to be implemented today it would not be a matching task. It would take two filesets, one the set of deployment descriptors to be processed and the other the support files to be included in the jar. In a particular use, I might want one to be a zipfileset to read the descriptors from a Zip and the other to be a classfileset to bring all the necessary support classes into the jar based on some root classes.
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.
Yes this is the problem with roles in this context. In mutant the user provides two pieces of info - one determines the method - this is the nested element name - and the other is the type of the instance to be passed to the method - this is supplied by the ant:type attribute.
<diff>
<fromFS ant:type="zipfileset" dir="htdocs/manual" prefix="docs/user-guide"/>
<toFS ant:type="classfileset" dir="build/classes">
<root classname="org.apache.tools.ant.Main"/>
</diff>
that is simple.
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
Well at least this would remove some of the hokiness.
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
