From: "Conor MacNeill" <[EMAIL PROTECTED]>
> Jose Alberto Fernandez wrote:
>
> > From: "Conor MacNeill" <[EMAIL PROTECTED]>
> >
>
> It does not need to be used all over the place. BTW, what in your view
> is the whole purpose?
>
Oh, I am not sure I understand your question completely. But to me one of the
main
points of this exercise is to eliminate all special cases (or as much as
possible) from
the code. 90% of the bugs in Datatype handling are due t the fact that we have
two
separate code lines, one for Tasks and one for Datatypes. After so many
revisions
supporting Datatypes, we still have bugs due to treating Tasks and Datatypes
diferently. If we were to support other "roles" the problem increase
exponentially.
I want to eliminate all that and have only one true way for everything. I am
not there yet
but my plan is to steadily get there. If you look at ProyectHelper there is no
special
handler for Datatypes anymore. If I have my way, we should finish with only
handlers
for NestedElements and Targets, and everything else should be done correctly by
the application of the composition rules. That means zero special cases and
ultimate
regularity in the code.
>
> >
> > I will do that when things are a little more stable, with so many ideas
> > comming from you
> > guys, I am still changing things around.
>
>
> I think it would help more people understand what is going on if you
> were to format and document it. I know what you mean about making
> changes but that is even more reason to keep Javadocs up to date.
>
OK, I have to confess I work on this from home, and with Emacs.
At work I have more sofisticated IDEs with formaters, Javadoc maintainers
etc. So it will take me a while to get to your standards. :-)
>
>
> I think basing it on the container interface is pretty ugly. It means
> that for every nested element that a task supports, which is to allow
> polymorphic elements, the task will need to implement a separate interface
>
> How long before we are implementing such a large number of interfaces
>
> myTask implements Filesettable, Mappable, Conditionable, Thingable, ...
>
Well, no matter what is done, you will have to define something,
either a method with an interface as argument (Peter's), or an interface
with a perticular method (Jose's). The interface is still there.
I think it is good that you have to declare those interfaces. The more
interfaces
you say you implement, the more chances for ambiguous situations there will
be. So one needs to be aware about that.
.
> You say you don't think there will be many roles defined. I disagree.
> Once typedefs become generally useful, i.e . once polymorphism becomes
> workable, people will be defining many roles. Also for this to be
> workable, the Task writer has to consider each nested element that he
> wishes to support polymorhpic behaviour. It cannot be added in after the
> task has been written (i.e. will need a recompile/new release).
Well, I do not equate roles with polymorphism. I see your point and the
potential
for abuse, but I really think that it would be the wrong way to go.
Roles are for defining the big cathegories, not the small ones. For example, a
Fileset
is defined as a Datatype, and in the datatype role, not in the Filesettable
role.
And you definetly do not want to define a different role for each posible type
that can be subclassed. For that fine grane level we need a diferent mechanism.
> For
> example, say someone wants to change the Javadoc task to pass in a new
> type of header (hypothetical example) from
>
> <javadoc>
> <header>
>
> to
>
> <javadoc>
> <superheader>
>
> If the author of Javadoc did not create and implement a Headable
> interface, you can't do anything.
>
As I said above, this is completely the wrong way to go on this particular
issue.
I am not sure how to do it, although I see how you resolve it using "ant:type".
>
>
> > Bt for some reason people dislike it (that is why we keep on having things
> > like <ejbjar>, <condition> etc.
>
>
> I'm not sure to what you are referring when you say people disklike
> "it". When has this sort of facility been implemented
>
It has not in general, but a very simillar approach managed by had by the user
code
is what is done in mappers, and it has been suggested for <condition> in the
past:
<condition type='not' >
<condition type='and'>
<condition type='equal'>
<arg value='1'/>
<arg value='2'/>
</condition>
<condition type='lt'>
...
</condition>
</condition>
</condition>
This is perfectly doable in ANT1 as is, but the syntax becomes ugly and tired
quite fast.
We have done such things for mappers. I think most people agree that we want
somethig
better.
>
> >
> > If your syntax where instead of the form:
> >
> > <foo>
> > <bar ant:role="thing" >
> >
> > Then at least I could see this syntax as a way to disambiguate things. But
> > I would
> > still like to make such attribute optional.
>
>
> It is optional, of course, only being required where you want to
> override the type normally expected by the task. So if I have
> <foo>
> <fileset>
>
> A fileset will be created automatically and used for the nested element.
>
See, we are talking about different things. You are talking about polymorphism
where you expect one type and instead you suply a subclass. I am refering
to RoleContainers where you accept things from a large family of posibilities.
For example there is no default or "normal" task to pass a container.
The only thing there is, it is a large family of posibilities.
> >
> > Whatever we decide, we need to take into account the restriction of not
> > breaking
> > ANT1 ad the way it does things. In perticular this means that mutant and
> > myrmidom
> > aproaches will not work because the syntax is incompatible with the tasks
> > already inexistance. That does not mean that my should be taken as is, I am
> > open for comments.
> >
>
> Having thought about this a bit more I think, besides the hokiness of
> having to implement a separate interface for every extensible nested
> element I want to support, there are problems when a task supports two
> nested elements with the same underlying type.
>
> For example, consider a task which takes two filesets
> <diff>
> <fromFS .../>
> <toFS .../>
> </diff>
>
> It has methods like this
> addFromFS(Fileset from);
> addToFS(Fileset to);
>
> I cannot have both of these being extensible. I couldn't use a
> classfileset for both since only one can be mapped to the interface
> method of the Filesettable role. I'm not sure myrmidon supports this
> scenario, if I read Peter's explanation literally, since it is searching
> for add(X x). Of course if it is were to search for
> addXXX(X x)
> methods, it wouldn't be a problem, I guess.
>
As I said, roles do not implement polimorphism which is what you want here.
I think this are different issues.How would you define a TaskContainer using
your notation? For example <sequental>, how would Mutant deal with
defining <sequential> without the special treatment TaskContainer has in the
code.
Jose Alberto
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
