Skip to main content

[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


Back to the top