| Re: [albireo-dev] thoughts on API |
All,
I agree. We'll need to think about it carefully though. 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.
Please note that SWT only discourages subclassing, but falls short of preventing it. I've always been of the school of thought that you can never predict all the future cases in which your software will be used. As a result, 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).
Over the years, we've run into cases in various frameworks in Eclipse across multiple projects where the developer locked the abstractions down so tight that the abstraction flexibility was almost completely removed. We need to admit that we simply can't know everything about how software will be reused. And, it should be the adoptor that determines what level of risk is appropriate for him to take when subclassing the code to add new functionality. That risk will include that his unanticipated style of reuse may break in subsequent releases.
So, I agree that discouraging and warning is appropriate where there are known dangers, but in the end, if an adoptor wants to "play with matches", he should be able to knowingly take the risk and do so.
For the hopelessly bored, I have a much longer post on an overlapping topic to this in Bugzilla in response to some proposed changes to WTP's package visibility: https://bugs.eclipse.org/bugs/show_bug.cgi?id=202711#c2
Regards, Todd