Add OfFloat.from methods in Point/Rectangle

[amartya4256]

This PR adds Rectangle.OfFloat.from and Point.OfFloat.from methods and removes the Win32DPIUtils.FloatAwareGeometryFactory class to make these methods OS-independent.

[github-actions]

Test Results

   546 files  ±0     546 suites  ±0   28m 2s ⏱️ - 4m 14s
 4 431 tests ±0   4 414 ✅ ±0   17 💤 ±0  0 ❌ ±0 
16 764 runs  ±0  16 637 ✅ ±0  127 💤 ±0  0 ❌ ±0 

Results for commit 59ed121. ± Comparison against base commit 508ad4a.

♻️ This comment has been updated with latest results.

[fedejeanne]

Before this PR one simply returned the same point (no instantiation).

Is there a reason for returning new Point.OfFloat(...) instead of just the existing pointOfFloat?

Same goes for the rectangles.

[laeubi]

I can only guess it is because of MonitorPoints that also Point.OfFloat but carry the monitor.

In general I think all these workarounds show that we have a major design flaw with the current way of how measure of position/sizes work and its to complicated to get right I therefore opened:

• Create a new more semantic API to measure Controls and set their bounds #2488

[amartya4256]

Yes, the from method is used to create a new object from the previous object. The idea is to allow any consumer to make a new Point.OfFloat object from any Point instance. We do not want to share the same instance as the consumer can manipulate this new object and we do not want to affect the old object. The from method semantically creates new object from the provided ones.

[laeubi]

We do not want to share the same instance as the consumer can manipulate this new object and we do not want to affect the old object

Should we probably (as far as possible) make the object unmodifable then instead? And instead make thing like "set" mor a copy of a new object?

[amartya4256]

Since the fields are public, we cannot make it unmodifiable completely, atleast not in a simple way. It will break all the consumers which reset these fields.

The idea of this PR is to move these helper methods which were implemented in DPIUtils and Win32DPIUtils inside the classes which should actually own it. I did such modifications in the from method only to make it semantically correct.

[fedejeanne]

Ok so basically you fixed a brittle design by making a defensive copy of the parameter. Something that wasn't happening before but should have happened.

I'm fine with that.

[laeubi]

I'm fine with that.

At a minimum the behavior must be documented (e.g. that you always get a fresh copy you are free to modify/use in any way).

Beside that only because on can modify x/y (int) it does not mean we should/must allow this for the Point.OfFloat returned here, so an API using Point.OfFloat might consequently simply never use the integer variants.

[fedejeanne]

I'm fine with that.

At a minimum the behavior must be documented (e.g. that you always get a fresh copy you are free to modify/use in any way).

@amartya4256 can you please mention it in the JavaDocs? Something like "Returns a new instance..."

[amartya4256]

sure.

[HeikoKlare]

Some questions on this proposal:

• Are the methods supposed to be public API or shall they only be used internal for now? In the latter case, they need to be marked @noreference. Otherwise, why do they need to be static at all and cannot just be toFloat(), as they become public API anyway? But since the classes themselves are currently @noreference, this method should probably be as well. In any case, they need a documentation.
• Since the methods are supposed to create OfFloat versions out of any other, wouldn't it make sense to place them inside Point.OfFloat, so that you write Point.OfFloat.From(something) instead of Point.from(something) but giving you an OfFloat instead of a pure Point.
• Is it correct and expected that a Point.WithMonitor loses the monitor information when passed to that method?

[amartya4256]

• Are the methods supposed to be public API or shall they only be used internal for now? In the latter case, they need to be marked @noreference. Otherwise, why do they need to be static at all and cannot just be toFloat(), as they become public API anyway? But since the classes themselves are currently @noreference, this method should probably be as well. In any case, they need a documentation.

We do not need @noreference since the classes are already marked with it. Adding the documentation to the method.

• Since the methods are supposed to create OfFloat versions out of any other, wouldn't it make sense to place them inside Point.OfFloat, so that you write Point.OfFloat.From(something) instead of Point.from(something) but giving you an OfFloat instead of a pure Point.

They are already inside Point.OfFloat.

• Is it correct and expected that a Point.WithMonitor loses the monitor information when passed to that method?

Adapting the method to call clone internally.

[HeikoKlare]

We do not need @noreference since the classes are already marked with it. Adding the documentation to the method.

They are already inside Point.OfFloat.

I see. I expected them to be in Point as obviously a minor version increment was necessary which I would not have expected for something effectively not being API.

You need to add an @since tag to the clone method implementation now.