RE: RE: [platform-swt-dev] org.eclipse.swt.SWT

[Steve_Northover@xxxxxxxxxx]

Erik, it's quite true that these things may not be "the way you would do it" but the time for
changing any of these things is long over.  We have API and we must support it.

I understand the "put the constants in the class" argument.  The challenge is to find a
sensible home for every constant.  Since this design decision is never changing, you
could go and do the work, find the home for every constant but it would be for fun only.
The results would be interesting, would show us how to be better next time, but we
couldn't use them.

I don't really understand the TypedListener scalability problem other than the obvious,
"I hate the case statement and casting, it's ugly".  TypedListener is really an internal class,
used by SWT to map from untyped to typed events.  It is not intended to be used outside
of SWT.  Here is the comment from the TypedListener class:

/**         
 * Instances of this class are <em>internal SWT implementation</em>
 * objects which provide a mapping between the typed and untyped 
 * listener mechanisms that SWT supports.
 * <p>
 * <b>IMPORTANT:</b> This class is <em>not</em> part of the SWT
 * public API. It is marked public only so that it can b!
e shared
 * within the packages provided by SWT. It should never be
 * referenced from application code.
 * </p>
 *
 * @see Listener
 *
 * @private
 */

Can you suggest a better implementation for us?

"Erik Poupaert" <erik.poupaert@xxxxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx 02/25/2003 05:10 PM Please respond to platform-swt-dev

To:        <platform-swt-dev@xxxxxxxxxxx>         cc:                 Subject:        RE: RE: [platform-swt-dev] org.eclipse.swt.SWT

>>>>> On the other hand, the whole constants/flag thing is pretty weak.  For
one
>>>>> thing, it's not clear by looking at a component class what properties
it
>>>>> supports.  You have to look at the JavaDocs to find out.  It's just
plain
>>>>> unwieldy trying to track down which SWT constants apply to which
components.

There are a number of design decisions in SWT that I consider:
not-what-I-would-have-done. This is definitely one of them. Another one is
org.eclipse.swt.widgets.TypedListener. Go and have a look at that one. That
is truly a showstopper to scalability. SWT does not necessarily excel in its
design beauty, certainly not everywhere.

What I find very good about SWT, is the fact that its results are really
nice and that it is multiplatform. Swing probably has a better looking
design, but its results are not always what we like. Further, I use SWT
jointly with GCJ to compile native applications. Swing would be out of the
question, because Gnu Classpath doesn't implement it (sufficiently), and
therefore, I would still be stuck with bytecode, it's startup conundrum, and
dragging around a JRE for deployment. My average GCJ/SWT executable is
self-contained and less that 1 Mb (with cheating because I compress with
upx). At present, there is no substitute for the combination GCJ and SWT.

So, it may be true that SWT is not designed nicely everwhere, but that fact
is compensated by other characteristics which make it a unique proposition.

>>>>> As components get extended and the API grows, this is just going to
get
>>>>> worse.

Bah. I hope the core of SWT will not grow. What is needed now, is a series
of potent widget-components. They don't need to be distributed along with
SWT. They could and probably should be separate projects.

>>>>> It would make sense to wrap all of these constants with set/get
methods, ala
>>>>> JavaBeans.  I realize JavaBeans isn't supported in SWT but having
properties
>>>>> declared via methods would make the users' lives much easier.  Under
the
>>>>> covers, the SWT programmers can still use the SWT constants to avoid
>>>>> breaking existing code.

I personally don't need the SWT developers to add anything. Let's just take
out the bugs, and grow this thing through other projects that build on it
and build in other dimensions. Nothing stops you from creating a project
consisting of purely wrappers that better reflect your own design tastes.

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev