[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [albireo-dev] thoughts on API, openness
|
Todd Williams wrote:
> I'd favor an approach that allows subclassing and easy access to all
> implementation details by subclasses (ie. exceedingly limited use of 'final'
> or 'private' modifier in the implementation).
I agree on this. Especially after I have seen the amount of troubles that
the many 'private' and 'package private' constraints of AWT and SWT cause.
You can get a feeling of the openness of a subsystem by looking at stacktraces
of programs that use that subsystem, and more precisely at those method
calls that come from methods in the subsystem. If, on average, 1 method out
of 2 is overridable, a user usually has no problems adapting the subsystem.
If however - and that's the case with AWT - 1 method out of 7 is
overridable, the user who needs to override something needs to duplicate
the behaviour of a call hierarchy 6 calls deep, or guess the situation
6 calls up depending on the set of arguments that are passed. This is
virtually impossible.
Gordon Hirsch wrote:
> If we allow
> subclassing, then there is a much larger burden to ensure future
> compatibility. There's a reason that SWT discourages subclassing of most
> widgets.
Backward compatibility can also be handled by keeping track of the
incompatible changes as they occur, listing for each change
- the date,
- the change,
- a migration guide from the old to the new state.
Especially while the number of users is small (<= 20), this provides
for a way to do incompatible changes while, at the same time, not upset
the users too much. Early adopters of a package are often willing to do
a few code changes here and there when given migration instructions.
Bruno