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

[Veronika_Irvine@xxxxxxxxxx]

SWT was designed with this philosophy.  I am just pointing out the fact 
that it was not random or done hastily.

You disagree with our philosophy and that is fine.  However, if you 
understand the philosophy you will see that it is actually applied 
meticulously within SWT.  We chose to make it easy to distinguish when 
things are done immediately and when an additional step is required. Using 
getters/setters in GridData will result in a loss of information which 
will have to be captured instead in Javadoc.





"Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx
02/27/2003 12:17 PM
Please respond to platform-swt-dev

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


> From: Veronika_Irvine@xxxxxxxxxx
>
> When a setter/getter is provided, it implies that calling that
> method will cause something to take effect immediately.

I disagree.  There are myriad situations where setters are used to set
attributes prior to executing an operation.  For example, setting a user 
ID
and password prior to an object access, or setting parameters prior to a
program call.

There is no conceptual difference between a setter and manually modifying 
a
public attribute, except that the latter has no constraint checking and
cannot require exception processing.  To program otherwise is to
deliberately go against years of object-oriented programming design
philosophy and to violate the basic concept of encapsulation.


> The use of public fields in
> GridData and GridLayout is deliberate.  In most cases, the application
> will update several fields and then to have the changes take effect they
> must call layout.  Since laying out widgets is expensive and can
> result in
> flash, you do not want to change each little thing one at a time
> and cause
> a layout to occur each time.

So don't do anything until the layout method is called.  That's what 
you're
doing today.  Again, no fundamental difference, just a reason not to
encapsulate your attributes (and not a particularly good one).


> This is a general design philosophy in SWT, not an oversight.

This philosophy goes against years of OO programming wisdom, and the 
entire
concept of an Exception.  A setter sets an attribute, but it allows the
creator of the class to check for constraints.  By making attributes 
public,
you allow users to set invalid values and thereby get unpredicted results.
Public attributes have been shunned for years for good reason.  There is
simply no valid reason to make attributes public.

Joe

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