Better API for handling MonitorAware Coordinates

[amartya4256]

This PR contributes to providing better interfaces and APIs for handling MonitorAware Rectangles and Points with Abstraction using prototype pattern.

All the Monitor Aware classes implement MonitorAware. Also th coordinate classes liek Rectangle and Point implement an interface copy. This should be introduced as a convention to use copy or copyWith, when a consumer wants to create a new object from the existing one. If there's any offsetting needed, the method copyWith can be used, making sure we copy all the abstract fields of the underlying Child class (if applicable) to the new object.

Also this PR introduces a new method Rectangle.of(Point, int, int) to make it easy to create rectangles using points instead of calling the Rectangle Constructor.

contributes to
#62 and #128

[github-actions]

Test Results

   545 files  ±0     545 suites  ±0   30m 33s ⏱️ + 3m 19s
 4 399 tests ±0   4 381 ✅ ±0   18 💤 ±0  0 ❌ ±0 
16 723 runs  ±0  16 582 ✅ ±0  141 💤 ±0  0 ❌ ±0 

Results for commit c5f86dd. ± Comparison against base commit e4890da.

♻️ This comment has been updated with latest results.

[fedejeanne]

I'm looking at this PR together with its first usage (eclipse-platform/eclipse.platform.ui#3005) and I have some questions (it might be that there are more consumers that haven't been adapted yet so I might be missing "the big picture", feel free to comment on that :-) ):

• Do we really need the interface MonitorAware? How is it helpful?
• I would remove the new method copyWith(...) if it's only necessary to copy and modify the receiver since that is something that the consumer can do on its own without "special handling" (no monitor-awareness, zooms, etc seem to play a role here)
• I see that Copyable is merely a "better named version of Cloneable" and it was probably added so that the methods copy() and copyWith(...) are associated with each other (?) . If that's the case, I think getting rid of copyWith(...) and replacing Copyable with Clonable is really a valid option.

[fedejeanne]

I now see that copyWith does not do any scaling nor does it do any special handling regarding monitor-awareness. This method is not really necessary, the consumer could simply use copy and then modify the coordinates and/or size on its own.

I mean doing this:

Rectangle r1 = ...
Rectangle r2 = r1.copy();
r2.x += dx;
r2.y += dy;
r2.width += dWidth;
r2.height += dHeight;

... instead of this:

Rectangle r1 = ...
Rectangle r2 = r1.copyWith(dx, dy, dWidth. dHeight);

[amartya4256]

The upper approach is not clean and the user might wanna rather call the constructor instead and create a new instance with the values. That's why having such API makes sense. Also had a talk with @akoch-yatta about it.

Also the API implementation can further be improved to update the monitor with respect to the offset as well (In case, the offset changes the monitor). Although that will be a separate issue.

[amartya4256]

• I see that Copyable is merely a "better named version of Cloneable" and it was probably added so that the methods copy() and copyWith(...) are associated with each other (?) . If that's the case, I think getting rid of copyWith(...) and replacing Copyable with Clonable is really a valid option.

Cloneable has clone() method as protected. If it is fine to override it to public without breaking the API conventions of SWT, I can use that for sure.

[HeikoKlare]

Overall, the change looks reasonable to me. Having proper clone functionality for those data classes is fine. I am not sure whether we can have a more expressive name for Rectangle.of.

Cloneable has clone() method as protected. If it is fine to override it to public without breaking the API conventions of SWT, I can use that for sure.

Note that Cloneable has not clone() method at all. clone() is defined by Object in Java and needs to be overwritten and made public in classes that implement the Clonable interface. I don't see that this can conflict with any conventions or contracts in SWT. Rectangle cannot be extended, so there is not chance that there is a conflicting overwrite of the method.

[HeikoKlare]

I have to admit that I don't understand why a MonitorAwareRectangle should not reveal that it's clone is a MonitorAwareRectangle. So I would be in favor of returning the actual/correct type here (also in the cloneWith) method.

[HeikoKlare]

To be more expressive, either the parameters should or the method name should be more self-explaning. E.g., call the parameters delta* instead of d* and/or call the method cloneTranslatedAndResized or the like.