> From: Peter Reilly [mailto:[EMAIL PROTECTED]
> For example there is an "or" condition, and an "or" selector.
> The patch allows these two to be defined as restricted typedefs:
>
> <typedef name="or"
> contract="org.apache.tools.ant.taskdefs.condition.Condition"
> classname="org.apache.tools.ant.taskdefs.condition.Or"/>
>
> <typedef name="or"
> contract="org.apache.tools.ant.types.selectors.FileSelector"
> classname="org.apache.tools.ant.types.selectors.OrSelector"/>
>
>
> The user-level issues would be:
> Is the attribute "contact" a good name for this attribute (use "role",
> "restrict", "instanceof" or ?).
I think 'contract' is a good name, to hold the classname to be honored.
I wonder though if you could add a bit of syntactic sugar to make the
declaration of restricted types easier, namely by allowing to map a contract
classname to a role name, such as:
<roledef name="condition"
contract="org.apache.tools.ant.taskdefs.condition.Condition" />
And then be able to say:
<typdef name="or" role="condition" classname="..." />
With XML namespaces in place, could be changed to role="ant1:condition".
But maybe it's a bit too convoluted, this added level of indirection!?
Within an AntLib.xml, just having contract is probably fine, but in the
context of a build file, reading role="condition" is nicer than
contract="org.apache.tools.ant.taskdefs.condition.Condition".
It's just an idea, I'm not saying it has to be that way ;-)
> Should this be a separate task and not typedef.
> For example:
> <nestedtype name="or"
> instanceof="org.apache.tools.ant.taskdefs.condition.Condition"
>
> classname="org.apache.tools.ant.taskdefs.condition.Or"/>
I'd say not myself. The contract attribute is enough for me to understand
this particular type is only valid within the context of the contract/role.
--DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
