You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Jose Alberto Fernandez <j_...@yahoo.com> on 2002/03/04 01:29:49 UTC
Name collisions
Hi,
As far as I can see in the current ANT1 code, there seems to be no provisions on what happens if I define
a task and a datatype using the same name. The definer tasks do not check across different namespaces.
It seems that Datatype definitions always take precedence over task definitions. Since under <antlib>
now we have the means to treat this issue in a proper way, I would like to know what do you think
should be the correct thing to do.
To make clear what is the situation I am referring to let me formalize it:
- Given two roles, A & B, triggered by the same container interface (e.g., task and data-type) and given that
a particular element name, N, is registered in role A, what should be the correct behaviour when one attempts to
register N in B.
Should the new definition be (a) rejected; (b) override the definition on A; (c) ignored.
Jose Alberto
Re: Name collisions
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 8 Mar 2002, Jose Alberto Fernandez <j_...@yahoo.com>
wrote:
> If I have A defined as a task, and I now try to define
> A as a data-type, should I:
> (1) redefine A (just like I would do if A was being
> redefined as a different task) or should I
> (2) fail because of trying to redefined to a
> different kind of thing.
(1) with a big warning.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Name collisions
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote: > On
Thu, 7 Mar 2002, Jose Alberto Fernandez
> <j_...@yahoo.com>
> wrote:
>
>
> "I don't want to touch this now" was talking about
> the main source
> tree, in no way would I want to restrict what you or
> anybody else is
> doing in the proposal area.
>
> Hope I've made myself easier to understand this time
>
Yes you have. And sorry for my "blow up" :-(
In any case, I still would like to get your opinion
on what should be the best behaviour to deal with this
issue:
If I have A defined as a task, and I now try to define
A as a data-type, should I:
(1) redefine A (just like I would do if A was being
redefined as a different task) or should I
(2) fail because of trying to redefined to a
different kind of thing.
This is my dilema and what I would like input from you
guys. (2) is much easier to implement, but (1) takes
the burden from library developers on having to know
the mappings of everything a priori.
Thoughts?
Jose Alberto
Jose Alberto
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Name collisions
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 7 Mar 2002, Jose Alberto Fernandez <j_...@yahoo.com>
wrote:
[basing roles on the things to add not the interfaces of containers]
> Which is backward incompatible with ANT1.x due to Tasks and
> data-types and TaskContainer signatures.
True - but only if you insist on making TaskContainer work with the
concept of roles instead of keeping it as an old, to become obsolete
solution for a particular problem. I'm willing to keep it as old
cruft (and drop it from Ant2 except in an Ant1 compatibility layer).
> Can you explain how to have general roles in ANT1.x,
> your way without filling the code with special cases
> for backward compatibility?
Honestly, no, as TaskContainer would remain as a special case.
> My only point is that in certain cases you can warn te user much
> earlier (at the moment where the declaration happens) and not wait
> until the usage.
If you can do that (which is not possible in general but in the case
of name collisions for tasks/data-types). I completely agree with
you.
> --- Stefan Bodewig <bo...@apache.org> wrote: > On
>
>> I want to wait how Costin is going to address this - I'm sure he'll
>> do - in the TaskFactory proposal he's working on.
>>
>
> Well, my proposal also has factories.
I know.
> But if the answer is, "whatever Costin will do is good and anything
> else is bad" well I guess I should just forget about asking and just
> pick a solution myself.
If this is the way you've read my statement, I must have been doing
something wrong.
Of course I could put in quick collision checks in Project, but both
your factories and Costin's factories are going to address this, at
least I think so. It is pretty likely that we'll decide how to
address this by comparing your approach and Costin's (they may even be
the same) and do something about it - after that the quick check would
be obsolete.
"I don't want to touch this now" was talking about the main source
tree, in no way would I want to restrict what you or anybody else is
doing in the proposal area.
Hope I've made myself easier to understand this time
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Name collisions
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote: > On
Tue, 5 Mar 2002, Jose Alberto Fernandez
> <j_...@yahoo.com>
> wrote:
>
> > If a container implements the interfaces for 3
> different roles (with
> > different interfaces) there is very little that
> one can do.
>
> Wait, I know that you are implementing roles that
> way in your antlib
> proposal, but it seems that Conor, Peter, Adam and
> myself prefer roles
> to be based on the type of the thing to add, not of
> the containing
> element.
>
Which is backward incompatible with ANT1.x due to
Tasks and data-types and TaskContainer signatures.
Can you explain how to have general roles in ANT1.x,
your way without filling the code with special cases
for backward compatibility?
> I think Adam has explained how Myrmidon deals with
> name clashes in a
> context where roles are not determined by the
> container.
>
I do this same thing already. My only point is that in
certain cases you can warn te user much earlier (at
the moment where the declaration happens) and not wait
until the usage.
> > So, even without <antlib> what shall we do in
> ANT1.x with the fact
> > that task and typedef declarations do not check
> accross each other.
> > That is a bug, since no warning or error is sent,
> but the
> > declaration is ignored.
>
> I agree, but I won't touch it know as I want to wait
> how Costin is
> going to address this - I'm sure he'll do - in the
> TaskFactory
> proposal he's working on.
>
Well, my proposal also has factories. I could have
just decide myself and implement some behavior. I
guess I was trying to be nice and see if we can get a
concensus. But if the answer is, "whatever Costin will
do is good and anything else is bad" well I guess I
should just forget about asking and just pick a
solution myself.
Some times it fills like there is not an even playing
field not even when doing proposals :-(
Jose Alberto
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Name collisions
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 5 Mar 2002, Jose Alberto Fernandez <j_...@yahoo.com>
wrote:
> If a container implements the interfaces for 3 different roles (with
> different interfaces) there is very little that one can do.
Wait, I know that you are implementing roles that way in your antlib
proposal, but it seems that Conor, Peter, Adam and myself prefer roles
to be based on the type of the thing to add, not of the containing
element.
I think Adam has explained how Myrmidon deals with name clashes in a
context where roles are not determined by the container.
> So, even without <antlib> what shall we do in ANT1.x with the fact
> that task and typedef declarations do not check accross each other.
> That is a bug, since no warning or error is sent, but the
> declaration is ignored.
I agree, but I won't touch it know as I want to wait how Costin is
going to address this - I'm sure he'll do - in the TaskFactory
proposal he's working on.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Name collisions
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: "Stefan Bodewig" <bo...@apache.org>
> On Mon, 4 Mar 2002, Jose Alberto Fernandez <j_...@yahoo.com>
> wrote:
>
> > As far as I can see in the current ANT1 code, there seems to be no
> > provisions on what happens if I define a task and a datatype using
> > the same name. The definer tasks do not check across different
> > namespaces.
>
> This is true.
>
> > To make clear what is the situation I am referring to let me
> > formalize it:
> >
> > - Given two roles, A & B, triggered by the same container
> > interface (e.g., task and data-type) and given that a particular
> > element name, N, is registered in role A, what should be the
> > correct behaviour when one attempts to register N in B.
>
> I'm not sure what triggered by the same container interface means
> here.
>
> In the case of tasks and data-type we only have a disambiguity because
> both can be defined within the same container elements (target for
> example), is this the "triggered by the same container interface" you
> are talking about?
>
Yes. The same container interface in that case is TaskContainer.
> If you want to generalize this to arbitrary roles, you cannot do
> anything at all, as you cannot know whether there is a context in
> which roles A and B both can be used at the same time, at least not at
> the point where things get registered. Or can you?
>
In the most general case that is true. If a container implements the interfaces
for 3 different roles (with different interfaces) there is very little that one can do.
But I would argue that that is not the regular usage escenario. The regular usage
(and the one present right now) is having several roles determine by the same
interface (e.g., TaskContainer) in such a case we know that all the elements in those
roles will always be available at the same time and therefore name clashes are
a thing to take into account.
So, even without <antlib> what shall we do in ANT1.x with the fact that
task and typedef declarations do not check accross each other.
That is a bug, since no warning or error is sent, but the declaration is ignored.
Jose Alberto
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Name collisions
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 4 Mar 2002, Jose Alberto Fernandez <j_...@yahoo.com>
wrote:
> As far as I can see in the current ANT1 code, there seems to be no
> provisions on what happens if I define a task and a datatype using
> the same name. The definer tasks do not check across different
> namespaces.
This is true.
> To make clear what is the situation I am referring to let me
> formalize it:
>
> - Given two roles, A & B, triggered by the same container
> interface (e.g., task and data-type) and given that a particular
> element name, N, is registered in role A, what should be the
> correct behaviour when one attempts to register N in B.
I'm not sure what triggered by the same container interface means
here.
In the case of tasks and data-type we only have a disambiguity because
both can be defined within the same container elements (target for
example), is this the "triggered by the same container interface" you
are talking about?
If you want to generalize this to arbitrary roles, you cannot do
anything at all, as you cannot know whether there is a context in
which roles A and B both can be used at the same time, at least not at
the point where things get registered. Or can you?
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Name collisions
Posted by Adam Murdoch <ad...@yahoo.com>.
> -----Original Message-----
> From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> Sent: Monday, 4 March 2002 6:30 PM
> To: Ant Developers List
> Subject: Re: Name collisions
>
> > 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" ... />
>
I imagine that types declared like this, would be added to a 'default' antlib, for the purposes of name resolution. The default antlib would have an empty name, or maybe the same name as the project.
So the above is fine, given that {antlib, role, type-name} is used for uniqueness. If {antlib, type-name} is being used, well, you're in trouble. Easy enough for the build file writer to fix, though.
> 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.
>
That's easy enough: Use an ambiguous name, the build fails. We need to figure out whether we either prevent any possibility of ambiguous names, or whether we want to give the build file writer a way to explicitly reference a type, when there is more than one alternative with the same shortname.
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Name collisions
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: "Adam Murdoch" <ad...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Name collisions
Posted by Adam Murdoch <ad...@yahoo.com>.
> -----Original Message-----
> From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Name collisions
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: "Peter Donald" <pe...@apache.org>
> On Mon, 4 Mar 2002 11:29, Jose Alberto Fernandez wrote:
> > To make clear what is the situation I am referring to let me formalize it:
> >
> > - Given two roles, A & B, triggered by the same container interface
> > (e.g., task and data-type) and given that a particular element name, N, is
> > registered in role A, what should be the correct behaviour when one
> > attempts to register N in B.
> >
> > Should the new definition be (a) rejected; (b) override the definition
> > on A; (c) ignored.
>
> Its a difficult question to answer 100% I think - because DataTypes in Ant1.x
> are used within same namespace. In practice I think it would be a good idea
> to make the base datatype class extend Task. I am not sure how feasible that
> is but it would solve quite a few of the inconsistencies with the model.
>
The problem is that in ANT1 data-types do not need to extend from DataType.
Anything can be a DataType.
> However if that is not the way then we should follow the same pattern we use
> for properties (ie silently ignore redefinitions unless go via a *privlidged*
> method). This is mainly for consistency.
>
Well we need to allow users to redefine tasks and data-types. We cannot just ignore it
always. The funny case is when things are comming from separate amalgamated spaces.
> 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. 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.
Jose Alberto
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Name collisions
Posted by Peter Donald <pe...@apache.org>.
On Mon, 4 Mar 2002 11:29, Jose Alberto Fernandez wrote:
> To make clear what is the situation I am referring to let me formalize it:
>
> - Given two roles, A & B, triggered by the same container interface
> (e.g., task and data-type) and given that a particular element name, N, is
> registered in role A, what should be the correct behaviour when one
> attempts to register N in B.
>
> Should the new definition be (a) rejected; (b) override the definition
> on A; (c) ignored.
Its a difficult question to answer 100% I think - because DataTypes in Ant1.x
are used within same namespace. In practice I think it would be a good idea
to make the base datatype class extend Task. I am not sure how feasible that
is but it would solve quite a few of the inconsistencies with the model.
However if that is not the way then we should follow the same pattern we use
for properties (ie silently ignore redefinitions unless go via a *privlidged*
method). This is mainly for consistency.
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).
Not sure - thoughts?
--
Cheers,
Pete
---------------------------------------------------
"Wise men don't need advice. Fools don't take it."
-Benjamin Franklin
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>