ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: IntrospectionHelper request
Date Sat, 12 Jan 2002 02:48:33 GMT
From: "Peter Donald" <>

> On Fri, 11 Jan 2002 15:42, Adam Murdoch wrote:
> > I'm not a big fan of Configurable, for two reasons:  It's an all-or-nothing
> > approach, where the object has to do all the work.  Granted, there are
> > helpers, but the object is responsible for doing the work.  I think in
> > almost every case, the task doesn't want to use a completely non-standard
> > scheme for configuring itself.  Instead the task simply wants to change how
> > a particular element or attribute is handled, and use the standard scheme
> > for everything else.
> How many tasks do you envision actually using this capability and which tasks 
> might they be ?
> > The other reason is that Configurable is totally opaque.  You lose
> > meta-info about the object, and so can't do things like configure it in a
> > GUI, or generate doco for it.
> Precisely ;)
> Which is why it will rarely be used. It is basically only there so that 
> people can do virtually anything they want - even if it is ludicrous. Many 
> people have asked for things like ability to define methods, funcitons, for 
> loops, various other containers and repeaters and so forth. Now none of these 
> is ever likely to be implemented or support by ant-dev but people still want 
> them. 

So you sre defining a whole mechanism whose one of its purposes is to be as dificult to use
as possible? And whose goal is to not be used. I think that is not a good designing rule.

> This gives them a method to do whatever they want so instead of saying no you 
> can't do X and we wont change it so that you can, we say we don't X but if 
> you really want it you can write a container to do it and support it yourself.
> Sure it will be rarely used in regular tasks but useful for some oddballs.

As I have said before, eventhough reflection is very powerful, it is not the end all solution
for everyone. What I cannot understand is why you first define myrmidon with all this flexibility
of having multiple implementations of ObjectConfigurer (by using an interface instead of a
firm implementation) and then you provide no easy way of using it. 

The problem with Configurator and passing the buck to the task is that since the job is not
easy it will require either that task developers reinvent the code that is already part of
myrmidon or for them to use internal myrmidon components in order to perform the configuration.
The result is that internal APIs will be exposed and therefore we will finish having the same
kind of backward compatibility problems that we have today in ANT1 and that we were suppose
to eliminate on ANT2.

The job of the container must be clear and must be always perorm by the container. The moment
you pass the work to the Task writer you will finish with all kinds of problems and dependencies
on the particuler implementation at the time their Task were written.

Jose Alberto

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message