ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject Re: Name collisions
Date Mon, 04 Mar 2002 08:29:47 GMT
From: "Adam Murdoch" <adammurdoch_ml@yahoo.com>
> 
> > From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> > 
> > > In ant2 it is likely that we will have types in different roles 
> > with the same 
> > > shorthand name. For instance myrmidon has a "classic" ProjectBuilder, a 
> > > "classic" Configurerr and a "classic" ProjectListener (all 
> > emulating ant1.x 
> > > behaviour). 
> > > 
> > 
> > Oh, you can do the same thing in <antlib>. That is not a problem. 
> > The problem is that
> > one also may have different roles whose namespaces have been 
> > amalgamated. 
> 
> Just out of interest, what does that mean exactly?  What is a role that shares a namespace
with 
> another role?
> 

It means that you want all those roles to be available in the same places and even in containers
that were defined before your new role existed. The case of task/data-type is
a good example. Another was the whole discussion about "beans without execute()".
In the <antlib> proposal you just define a new role "superbean" using the TaskContainer
interface
and providing the new SuperBeanAdapter and presto! you can use these beans any place
a task can be used. 

Simple and powerful.

> > This
> > happens when 2 roles use the same definition for the container 
> > interface (with different 
> > adapter, for example). This is the mechanism used in <antlib> to 
> > model the behaviour
> > of task and data-type. Data-types can be used anywhere a task can 
> > be used  which means that they use the same container interface.
> > 
> > The issue is what to do in this amalgamated name space situation.
> > 
> 
> For Ant 2, I guess there's a few things we can do.  One option would be to use the {antlib,
role, > type-name} combo, to uniquely identify each type.  It's an easy constraint to enforce,
and
> something that the task writer has complete control over.
> 
> The type-name should be usable on its own, unless it is ambiguous.  In the cases where
it is 
> ambiguous, the build file writer needs to be able to tell us explicitly which one they
mean to use.  > Some options:
> 

So what happens if I just do:
    <typedef name="A" ... />
    ...
    <taskdef name="A" ... />

not from a library but from an on the fly definition (like when one compiles and uses the
task on the same build.

> * Have the ability to alias a type when imported.
> 
>   <import lib="lib1">
>     <task name="copy" alias="copy1"/>
>   </import>
> 
>   <copy>
>   <copy1>
> 

You can do this in <antlib> but the point is what does the system should do if you do
not
do that.

Jose Alberto



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message