----- Original Message -----
From: "stephan beal" <[EMAIL PROTECTED]>
> For example, for efficiency i'd like to use runExecute(), so i can set up
one
> Execute object and re-use it, instead of going through the whole Execute
> creation/setup environment, etc., on each loop. i can't with ExecTask
because
> runExecute() is protected.
So perhaps that functionality should be refactored out of ExecTask and into
the Execute object itself? Or into some other class? Just some ideas to
keep from having to re-use an actual "task". To me it seems best to hide
the implementation details of a task and not expose it except through the
necessary setter and execute methods.
> But the whole point of objects is re-use, not copy/paste. i can understand
> why you think tasks shouldn't be nested, and i would never consider
> subclassing (for example) a core task from an optional task. But if all
> involved tasks are core it shouldn't be a problem. In fact re-using them
> would be following one of the points from the Ant development guidelines:
> don't re-invent the wheel.
>
> After all, protected methods are, by definition, made for subclassing, so
> there is no use whatsoever in providing protected methods if the class is
not
> intended to be subclassed. Certainly the class designer expected that the
> protected functions would be useful to subclasses.
>
> Another argument for subclassing AbstractCvsTask is that the Cvs task is a
> front-end for running an external program (i.e., it's a more specific case
of
> ExecTask). i can't think of anything the AbstractCvsTask can do that you
> can't also do with ExecTask, and that (to me) says "subclass it!"
(To me) it says "refactor it" - inheritance is a last resort! :)
Erik
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
