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

[Scott Stanchfield <scott@xxxxxxxxxxxx>]

> >>>> Not quite -- SWEET isn't an SWT wrapper of any sort.
> It's an effort to
> >>>> build a set of peers similar to BeanInfo classes
> (preferably extensions
> >>>> of BeanInfo) that can describe SWT classes so they can
> more easily be
> >>>> used in UI builders.
>
> Well, since BeanInfo requires defining getters and setters
> and other stuff,
> I guess it boils down to creating a normalizing wrapper, doesn't it?
> Wouldn't the results satisfy, as well, the afficionados of
> more orthodoxy in the design of the APIs?

Nope. I said "similar to BeanInfo". (Note, however, that BeanInfo does
not require "get" and "set" methods; you can change which methods are
read/write methods... But for BeanInfo, their signatures must be the
same.)

I am dead-set against any wrapper-based approach for the following
reasons (if I took more time I might be able to think of more):

1) Adds more weight to SWT apps, just to make a similar API to Swing.
There is nothing more "right" in Swing's design; it's just different...

2) Wrappers like this have a tendency to dumb-down what you can do with
the underlying components. They usually take a least common denominator
approach, so that if you can't directly represent some aspects of the
underlying component in the paradigm the wrapper is trying to allow,
those aspects are usually left out.

3) Wrapper maintenance is a bear if the wrappers are not maintained by
the component writers themselves. This tends to make the wrapper lag the
component, often losing functionality or creating inconsistencies.

4) A wrapper provides a new layer in the runtime of the application that
can introduce bugs.


Note that some kinds of wrappers are necessary and good for design
(patterns like GoF Adapter, for example) to really convert one form to
another. This is not what's being suggested, however. When people talk
about putting YAA (Yet Another API) on top of SWT just because they
don't agree with the current SWT API, that's adding an unnecessary extra
layer.

What's really needed for SWT to be comfortable (IMHO) is the right set
of documentation, especially docs that say "if you did X in Swing,
here's how you would do it in SWT".

Last I checked, programmers tend to be a bright bunch and can learn a
(slightly) new paradigm for GUI creation; it's really a matter of making
sure they can find the information they need.

-- Scott

==============================================================
Scott Stanchfield    scott@xxxxxxxxxxxx    http://javadude.com

Lead author of "Effective VisualAge for Java, Version 3"
                                      http://javadude.com/evaj

VisualAge for Java Tips and Tricks     http://javadude.com/vaj
Visit for Java Enlightenment!             http://www.jguru.com
==============================================================