In order to be portable, each SWT platform
has the same public classes and these classes have the same API. TextBase
could not be a public class or this would violate portability.
Is it implementation or API that you
want to share? Generally speaking, we will either copy the code (if
it is small) or share the implementation by defining non-public methods
in a common superclass and passing parameters. It's a bit ugly because
other classes inherit methods that are of no use to them, but it shares
code and is not part of the API. We prefer this approach over introducing
classes on some platforms and not on others. Since most of the real
work is happening in the operating system, generally speaking, the amount
of copied or shared code is not that huge.
There is another (smaller) issue. SWT
committers normally maintain and implement code on all platforms. Keeping
implementation strategies and the same classes avoids context switches
when switching between platforms.
<gercan@xxxxxxx> Sent by: platform-swt-dev-bounces@xxxxxxxxxxx
09/25/2008 07:06 AM
Please respond to
"Eclipse Platform SWT component developers list."
[platform-swt-dev] Adding implementation
classes to SWT hierarchy
I am trying to create a common place to capture the text editing
functionality so that they can be shared among Text and Combo .
Looking from the class hierarchy the place to do such a thing would be
Scrollable. However I do not think such a functionality has any place
in Scrollable so is it OK to introduce an TextBase class that inherits
Scrollable so that Text and Combo can inherit the base text
functions.? This would be an implementation class that should not be
used by the clients however I have not seen such a case in the
implementations so far I wanted to check.
platform-swt-dev mailing list