> -----Original Message-----
> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> Sent: Monday, 4 March 2002 1:00 PM
> To: Ant Developers List
> Subject: Re: Name collisions
>
>
> > 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?
> 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:
* Use fully qualified type names, e.g. antlib.role.type:
<import lib="lib1"/>
<import lib="lib2"/>
<lib1.task.copy .. >
<lib2.task.copy .. >
* Similar to Java, an explicit type import has precedence over an implicit
import, and it is an error to explicitly import 2 types with the same
shorthand. This option wouldn't work on it's own - it would need some way to
use the implicitly imported types too. It's just a convenience.
<import lib="lib1">
<task name="copy"/>
</import>
<import lib="lib2" />
<copy .. >
<lib2.task.copy .. >
* Have the ability to alias a type when imported.
<import lib="lib1">
<task name="copy" alias="copy1"/>
</import>
<copy>
<copy1>
* Use attributes to provide the missing pieces of information, so that we end
up with antlib, role and type-name. In some contexts, the role may not be
needed.
<copy ant:lib="lib1" ant:role="task"/>
Another option would be to drop the role from the unique identifier. This fits
better with how javadoes things. A type's role doesn't have anything to do
with its packaging (the analogy with java is antlib == package, role ==
interface). Just like Java, packaging is where we want to do the
disambiguation
Adam
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
