[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] Adding implementation classes to SWT hierarchy

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.  

"Gorkem Ercan" <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@xxxxxxxxxxx>

[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