> From: stephan beal [mailto:[EMAIL PROTECTED]
>
>
> On Saturday 23 March 2002 00:57, you wrote:
> > > -----Original Message-----
> > > From: stephan beal [mailto:[EMAIL PROTECTED]
> > >
> > >
> > > On a related note: is there a good reason for not making Task an
> > > interface,
> > > and supplying an AbstractTask to subclass? Except for some
> > > "extends ..." and
> > > "implements ...." lines i can't imagine this not being
> > > backwards-compatible.
> >
> > Well, almost every task in existence today "extends Task". Make Task an
> > interface and they ain't going to work any more. You'd be hard
> pressed to
> > argue that that is backwards compatible.
>
> sed is our friend:
> s/extends Task/extends AbstractTask/
>
For the sake of argument, let us say you create:
interface Taskable {
...
}
abstract class AbstractTask implements Taskable {
...
}
class Task extends AbstractTask {
//Adapter class for AbstractTask
}
class FooTask extends Task {
}
You would have to do this at a minimum to make sure
that we do not annoy the folks who have invested time
and energy to create custom tasks like FooTask.
Though at the outset this would seem like no
harm will be done, it will: take a look at my comments
on http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5997
So, in summary, though it *might* seem reasonable
to refactor Task into interface/abstract/adapter
type hierarchy, it wouldn't be backwards compatible.
We cannot break backwards compatibility in Ant1,
especially at such a basic (foundation) level.
If you can work around this problem, then, maybe,
there will be no objections to you proceeding
with such refactorings... ;-)
Cheers,
Magesh
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
