I also think the roles concept is good for the following reasons:
* The current implemention of conditions/selectors/filters (a
big sequence of add<Name>()) is tightly coupled.
The implementation means that new conditions/selectors/filters
(to be used in the same way as current conditions/selectors/filters)
mean modification to core ant code. This is not nice and not
in the spirit of adding new datatype and new tasks.
* Use of the add(Type) pattern allowing datatypes/tasks to
be used partially addresses this. But it is not a complete
solution: the names are global, current selectors/conditions
are not, currently use of "and" is context-dependant, it is
both a selector and a condition and cannot be used in a target
or at the top level.
The only issue with roles is how to implement them so that the definitions
defined behave in the same way as current conditions/selectors and the
big sequence of add<Name>() methods could be removed. (For BC reasons
they will never be removed ;-)).
My proposal is that <typedef/> is extended (again) to have the
attribute "role" which restricts this definition to only be used
only in the context of add[Configured](Type) and the polymorhic attribute.
A snippet from the antlib.xml file for ant: (after removing
the explicit add<Name>(..) methods from ConditionBase and the
interface and various impls of SelectorContainer.
<!-- =================================================== -->
<!-- Define a number of roles -->
<!-- =================================================== -->
<extendtype name="conditiondef">
<typedef role="org.apache.tools.ant.taskdefs.condition.Condition"
onerror="report" />
</extendtype>
<extendtype name="selectordef">
<typedef role="org.apache.tools.ant.types.selectors.FileSelector"
onerror="report"/>
</extendtype>
<!-- =================================================== -->
<!-- conditions -->
<!-- =================================================== -->
<conditiondef name="not"
classname="org.apache.tools.ant.taskdefs.condition.Not"/>
<conditiondef name="and"
classname="org.apache.tools.ant.taskdefs.condition.And"/>
<conditiondef name="or"
classname="org.apache.tools.ant.taskdefs.condition.Or"/>
<!-- =================================================== -->
<!-- selectors -->
<!-- =================================================== -->
<selectordef
name="and"
classname="org.apache.tools.ant.types.selectors.AndSelector"/>
<selectordef
name="contains"
classname="org.apache.tools.ant.types.selectors.ContainsSelector"/>
Peter
On Thursday 22 May 2003 10:37, Antoine Levy-Lambert wrote:
> I think that roles add clarity to description of datatypes or components. I
> liked the syntax of the antlib descriptor proposed by Jose Alberto, which
> in my example with shapes would have been :
> <antlib version="1.5" >
> <task name="computearea" class="org.apache.demo.ComputeAreaTask"/>
> <task name="computeperimeter"
> class="org.apache.demo.ComputePerimeterTask"/>
> <role name="shape" class="org.apache.demo.ShapeInterface"/>
> ...
> <shape name="circle" class="org.apache.demo.Circle"/>
> <shape name="square" class="org.apache.demo.Square"/>
> ...
> </antlib>
> Reading this, and knowing that computearea and computeperimeter accept
> shapes as nested element, a build file writer would know that <circle/> and
> <square/> can be nested inside <computearea/> and <computeperimeter/>. This
> descriptor also says that ShapeInterface should have a special meaning for
> ant, which for instance Serializable, Cloneable, ... do not necessarily
> have.
>
> However, if , as it sounds, I am the only committer who expresses support
> for roles, I will give up on that subject.
>
> Antoine
>
> ----- Original Message -----
> From: "Costin Manolache" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, May 22, 2003 7:02 AM
> Subject: Re: antlib
>
> > Conor MacNeill wrote:
> > > On Thu, 22 May 2003 01:02 am, Jose Alberto Fernandez wrote:
> > >> Whatever we adopt, it definetly need to be written from scratch. :-)
> > >
> > > Cool. All I had to go on was the code. If we agree that roles are based
>
> on
>
> > > the interface implemented by the nested element, that is good. It was
> > > my main concern. I still don't really see the need for roles but that's
>
> just
>
> > > me :-) Go for it.
> >
> > I don't think it's just you, I'm on the same side.
> >
> > Probably a small poll on the remaining issues would help clarify where
> > the majority stands. I think most people are willing to accept a range of
> > solutions, and a lot is a matter of taste and prefference.
> >
> > So far I've heard the strong opinion of Jose on roles - and I'm not sure
> > on the other's opinions. There are 2 negative opinions so far. If we
>
> decide
>
> > to add roles, I would like to be clear where other committers stand.
> >
> > Costin
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
