On Sat, 12 Jan 2002 13:48, Jose Alberto Fernandez wrote: > > 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?
errr .... love to hear of a simpler system that comes even vaguely close in flexability. Try coding the configurator approach and get back to me on which you think is easier. > And whose goal is to not be used. The goal is to be used - when people need to do things we are not willing to do they have the option of getting around us. > I think that is not a good designing rule. I think it is a good rule to actually code/experiment with the things you are talking about before talking about them - have you done that ? > > 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. I didn't do that part ;) I left it as an interface because it may be possible to experiment with these things and see how they work out. > 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. Umm ... I have talked about this before - this wont be a problem if they extend AbstractTaskContainer because they will never be exposed to low level APIs. -- Cheers, Pete *------------------------------------------------------* | "Common sense is the collection of prejudices | | acquired by age 18. " -Albert Einstein | *------------------------------------------------------* -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
