Hi Chris,
On Sat, 2004-12-18 at 11:32, Chris Lambrou wrote:
> >Someone suggested that for Log, it would be appropriate to make it an
> >abstract class rather than an interface, so we can make these kinds of
> >changes easier in the future.
That was me (inspired by Robert Donkin's enthusiasm for using abstract
classes rather than interfaces in digester).
> >I think the risks for this are low, and
> >probably better [less problems for the majority of users] than just adding
> >new methods to the existing interface. Other thoughts on this direction?
> >
> >
> I think the risk of annoying quite a number of users by changing Log
> from an interface to an abstract class is actually quite high. For sure,
> one of the default logging implementations provided by JCL would
> probably suffice for the majority. However, there are groups who will
> have chosen, for whatever reason, to provide their own logging
> implementations. I've certainly worked on a couple of projects where
> this has been the case. One of them could probably cope with the change
> relatively easiliy, but such a change could be a real pain for the
> other. Whilst the proportion of JCL users in this situation is probably
> quite small, in terms of actual numbers, such a change could cause quite
> a lot of grief.
First, I was suggesting that instead of introducing a *new* *interface*
(Richard's proposal) to provide an extended API that a *new* *abstract
class* be introduced. Neither of us were proposing changing the existing
Log interface.
But if the Log interface were to be changed, then adding methods to it
would break binary compatibility. The most obvious way is that classes
that were previously valid implementations of the interface become
incomplete.
Suppose for a moment that we were to choose between adding methods to
the Log interface, and turning it into an abstract class with some
methods; I don't understand what "real pain" would be incurred by having
custom logging adapters be declared as:
public class FooLog extends Logger {...}
instead of the existing
public class FooLog implements Log {...}
Sure there would be some inconvenience, but wouldn't it be the same as
having to update the existing log implementation to add implementations
for the new methods added to a Log interface? Making this sort of change
would indeed "annoy" users as they couldn't used their existing
log-specific adapters with the new JCL release without modifying them.
But that would be the case even if the Log class remained an interface.
And once a move to using abstract classes has been made, we *can* extend
the API later without breaking binary compatibility as long as a
reasonable default implementation can be provided.
The only problem would be if someone had an adapter class that for some
reason needed to extend some other existing class. But I don't see why
that would happen for a logging adapter, and there are reasonable
workarounds for this anyway (eg using a trivial inner class).
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
