Improve API for cloning/creating rectangles

[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   28m 17s ⏱️ +14s
 4 399 tests ±0   4 381 ✅ ±0   18 💤 ±0  0 ❌ ±0 
16 723 runs  ±0  16 583 ✅ ±0  140 💤 ±0  0 ❌ ±0 

Results for commit 128175b. ± Comparison against base commit e39c288.

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

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

[laeubi]

Just an idea:

Do we really need an own class here? Can't we add a (package protected?) field to the regular Rectangle and mark it as not for public use like we do with the handles in Control?

[HeikoKlare]

Just an idea:

Do we really need an own class here? Can't we add a (package protected?) field to the regular Rectangle and mark it as not for public use like we do with the handles in Control?

The class already exists. This change just adds further functionality.

Back then, we also discussed adding a field to the existing Rectangle class, but there are at least two reasons against it:

• The Rectangle is a quite general type: it is used all over the place and adding another (usually useless) field unnecessary bloats up instances
• A pure Rectangle has nothing to with a monitor (as it is not semantically tied to a monitor), so adding such a field would be strange also regarding the class' semantics.

[laeubi]

If that holds true then one should actually not extend Rectangle but e.g. use a record that combines a rectangle with a monitor.

[HeikoKlare]

If that holds true then one should actually not extend Rectangle but e.g. use a record that combines a rectangle with a monitor.

If it's not a subclass, you cannot pass it via existing APIs that accept or return instances of Rectangle.

[laeubi]

If that holds true then one should actually not extend Rectangle but e.g. use a record that combines a rectangle with a monitor.

If it's not a subclass, you cannot pass it via existing APIs that accept or return instances of Rectangle.

The obviously the monitor is an important property in some cases and there are only others where it is irrelevant. This is similar to how we do it with Events where some fields are filled and others are not depending on the context / usage. I also don't see that we create millions of Point/Rectangles that the object size actually matters.

So either we should have new API that accepts a Point/Rectangle + Monitor or we should account for the fact that the monitor is a property of a Rectangles or point. Having only internal used classes with marker interface and trying to restrict what we made public seems not very useful and complicates the matter more than it solves it.

[HeikoKlare]

Having only internal used classes with marker interface and trying to restrict what we made public seems not very useful and complicates the matter more than it solves it.

Why? And what's the marker interface here?
I have to admit that I don't see the problem that we need to address. Unless it's necessary and well designed to expose a propery, why should we do that?
The proposed API for cloning rectangles in this PR is even reasonable independent of whether there are monitor-aware specialization or not.

[HeikoKlare]

I've corrected wrong code formatting and added the necessary version bump commit, as a minor bump for SWT is required due to added API.