On 9/13/06, Matt Benson <gudnabrsam@yahoo.com> wrote:
>
> --- Dominique Devienne <ddevienne@gmail.com> wrote:
>
> > > I did not see the changes. But in principle I
> > agree with Dominique
> > > that a roledef should have 3 attributes :
> > > name, role, classname
> >
> > Just to clarify, I like the way Peter implemented it
> > (binding a class
> > to a name, without specifying what "role"s this
> > class should play).
> > But the term "role" also implies to me a (name,
> > role, classname)
> > tupple, which is why I'd prefer not using <roledef>,
> > that's all.
> >
> > Last night I thought that <componentdef>, although
> > longuish, might be
> > a better term than <elementdef> or <tagdef>. --DD
>
> <componentdef> is okay, given ComponentHelper, etc.
> But agreed, long.  What about <def>?  Am I correct in
> assuming we'd have, with whatever name:
>
> <xxx name="and"
> classname="oata.taskdefs.condition.And" />
>
> <xxx name="and"
> classname="oata.types.selectors.AndSelector" />


Yes, this is the case.
My  original idea was:

<typedef restrict="yes" name="and" classname="oata...conditon.And"/>
<typedef restrict="yes" name="and"
classname="oata...selectors.AndSelector"/>


?
>
> Then what about <adaptdef> or <flexdef>?


Other names:
 <restrictdef>
 <classdef>
 <subdef>

 <compodef> (just kidding).


For me:
<componentdef> sounds the best. Do not forget that
this will probally not be used outside the ant core code as
the resultant name may not be used at the top-level, or
in targets - or sequential bodies.

Some classes thus may have multiple names associated
with them, a unique top-level name and a restricted name that
can be s


-Matt
>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail:
> > dev-help@ant.apache.org
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>