From: "Peter Donald" <[EMAIL PROTECTED]> > 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
