Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: RE: [platform-swt-dev] org.eclipse.swt.SWT


There was a PR which encapsulates the SWT team's philosophy about class Point.
        See http://dev.eclipse.org/bugs/show_bug.cgi?id=4460

The relevant details...

This entire discussion presupposes that an SWT Point is somehow related to the
more mathematically oriented "Point" you find in AWT and elsewhere. You need
to understand that this is *not* such a beast.

In SWT a Point is simply a data structure with two slots, used to pass values
to OS routines which require that shape. It does not have interesting API,
since the operating systems SWT is built also do not.


Please read the PR before commenting further. (Note: apologies in advance for another of the "We've been doing this longer than you" rants. I *will* eventually figure out that they don't add value.)

McQ.



Scott Stanchfield <scott@xxxxxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx

02/28/03 11:40 AM
Please respond to platform-swt-dev

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



I think you missed my point...

The point is that should be no need to reinvent the wheel here.

In a drawing tool, a Point model *is* a set of coordinates. There's no
difference between intended use. I'm using a Point object to keep track
of some location somewhere. Whether it's used for actually drawing on
the screen or keeping track of data that's not currently display, makes
no difference.

Subclasses could tweak the usage for specific scenarios if needed.

-- Scott

> -----Original Message-----
> From: platform-swt-dev-admin@xxxxxxxxxxx
> [mailto:platform-swt-dev-admin@xxxxxxxxxxx]On Behalf Of
> vellapillli_h.indukumar@xxxxxxxxxx
> Sent: Friday, February 28, 2003 10:42 AM
> To: platform-swt-dev@xxxxxxxxxxx
> Subject: RE: RE: [platform-swt-dev] org.eclipse.swt.SWT
>
>
> With respect to SWT or Swing for that matter, I believe that
> Point need not
> have getters and setters. If you are using SWT/Swing to
> create a drawing
> tool, you would be better off using your own custom class to
> represent a
> point. In case of a drawing tool, Point is a model and not
> coordinates. In
> SWT/Swing, a Point represents a coordinate. There are conceptual
> differences between them. So I would suggest you have
> something in the line
> of PointModel with getters, setters etc.
>
>
>
>
>
>                               Scott Stanchfield
>
>                            <scott@xxxxxxxxxxxx>           To:
>  platform-swt-dev@xxxxxxxxxxx
>                         Sent by:                          cc:
>
>                         platform-swt-dev-admin@
> Subject:   RE: RE: [platform-swt-dev]
>                         eclipse.org
> org.eclipse.swt.SWT
>
>
>
>
>
>
>                             02/28/2003 04:27 PM
>
>                               Please respond to
>
>                                platform-swt-dev
>
>
>
>
>
>
>
> > I agree with your points if the Point class is to be used
> > inside a Drawing Tool.
>
> This is the problem, IMHO. When someone designs a class,
> there's no way
> they can know all the possible places that class is truly useful.
>
> Why should there have to be multiple Point classes? The concept should
> be incredibly reusable. If it had been designed
>
>   class Point {
>     private int _x, _y;
>     public int getX() {return _x;}
>     public int getY() {return _y;}
>     public void setX(int x) {_x = x;}
>     public void setY(int y) {_y = y;}
>   }
>
> it could later be modified or subclassed to provide
> additional services
> such as notification, or different implementations such as automatic
> origin translation.
>
> As it currently exists, the only way to have a notifying Point, is to
> create an entirely new class...
> Something that could have been infinitely reusable, isn't...
>
> Bottom line: Three of my "rules of reuse" apply here:
>
> * (rule 1) All data must be private
> * (rule 2) Most (if not all) data should be exposed as JavaBean
> properties (ie getters/setters)
> * (rule 4) The get/set methods should be protected (or
> better, public),
> so subclasses can override and call
>
> (I think I might need to add another rule -- all objects must
> be created
> via factories, so the factory could replace the actual type of object
> returned with a subclass under certain circumstances... hmmm...)
> -- Scott
>
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>
>
>
>
>
>
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>
>
>


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


Back to the top