On Mon, 7 Jan 2002 06:40, Erik Hatcher wrote: > ----- Original Message ----- > From: "Peter Donald" <[EMAIL PROTECTED]> > > > Most likely I would -1 it but it would depend upon how it was implemented > > essentially. I think it is really poor design of tasks that would require > > this and would almost certainly reject any task that used it ;) > > I would implement it using the interface that I proposed, and that Jose > refined. Simple as that, and probably would only involve a few lines of > code (at least it should :).
ok will actually have a proepr look at it tonight ;) > Would you -1 that implementation? I just want to know before I code it and > get shot down! :) Theres plenty of things - will have a look and tell you if I don't like. However the main reason I would -1 is because it is only a workaround for a limitation of ant and I don't want to be supporting more ugly hack workarounds into the future ;) > How does implementing this open the flood gates to bad things? Increasing the "surface area" of a project always comes at a cost. If the cost can not be justified by added features etc or the cost is not offset somehow then it is probably a bad idea to add specific feature. We already have oodles more "join points" (ie places where we are flexible) than we actually need if it had designed it properly from the start. Where we have numerous patterns for things like addX createX addConfiguredX setX we could have probably gotten away with just addX setX or even just setX if we didn't want to make to much of a distinction between elements/attributes. Think of it this way. Give ant 50 points for every minor feature and 100 points for every major feature. Then subtract 5 points for every "access point" (ie public/protected methods/attributes) and subtract 100 points for every structure/pattern required and 10 points for every public class. The higher the result the better ant is from both a user and developers point of view. However I think ant would actually score rather low as it has a whole bunch of tasks written in an "interesting" manner. Some have public attributes (!!!), many include numerous protected/public methods that don't need to be public/protected, we have many replicated/redundent patterns/classes that come from different stages of ants evolution etc. > > So far I haven't actually seen a good use for it. Can you give me a good > > use > > > case ? The only one provided is directly due to limitations in Ant1.x > > model. > > > When these limitations are removed there would be no need for DynaTask. > > So besides the specified case have you got another example ? > > The XDoclet use-case is the only use-case I have in mind now. That makes me less inclined to support it if anything ;) > Keep in mind that I'm of the opinion that Ant probably should be using > XDoclet in the future to allow a lot of a tasks configuration to be > specified in meta-data allowing documentation to be generated as well as > any other artifacts needed (configurator Java classes perhaps?). Sounds kool Could you give us an example of what something like that would look like? and have you played with any of it yet? -- Cheers, Pete *------------------------------------------------------* | "Nearly all men can stand adversity, but if you want | | to test a man's character, give him power." | | -Abraham Lincoln | *------------------------------------------------------* -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
