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

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> 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.

Wait a second.  Are you implying that the entire SWT API is cast in stone
and cannot be changed?  Because you might want to reconsider that idea.  SWT
is not ready for prime time.  For example, throughout SWT you have exposed
the various attributes of classes without supplying setters and getters.
(An example is the GridLayout object.)  Are you saying this is going to stay
this way?

If so, why?  Why would you go against all the normal conventions of Java
programming?


> Why?  Now there would be 2 ways to do the same thing, using more space.
> Not worth it.

"Using more space"?  Why do you think it's important to "save space" at the
expense of ease of use?

In my opinion, SWT is an API that isn't quite ready to be released to
ordinary programmers, sort of like the earliest releases of AWT.  It is
functional, but it needs a lot of work to be truly usable.  You need setters
and getters with the appropriate error checking for all your attributes, as
well as convenience methods on your constructors to avoid the majority of
temporary variables.  APIs are great, but they can change.  And now is the
time to do it, before you have a large base of code using them.

If your argument is that the current SWT API is a "lean and mean" stripped
down version written for speed over accuracy, well great, but then you need
a wrapper layer around it for more traditional programming that does all the
error checking and convenience coding that makes something usable by less
adventurous programmers (that is, most of us).

Joe