Mixing signatures for ScreenToX between int and Point

[tznind]

ScreenToContent uses Point
ScreenToViewport uses int,int
ScreenToFrame uses int,int

Is it possible to please standardize these? or is there a reason they are not consistent.

It makes debugging screen pointer issues difficult if you are trying to switch between the two methods to see which is more correct.

[tig]

I agree.

Your preference? Point or two int?

[tznind]

I think point makes most sense as that is the return type too. Also eliminates any chance that someone gets the args the wrong way around (I.e because there will only be 1). But happy to be persuaded otherwise if there is any performance or elegance factor others can see.

…

On Wed, 8 May 2024, 21:30 Tig, ***@***.***> wrote: I agree. Your preference? Point or two int? — Reply to this email directly, view it on GitHub <#3460 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHO3C5EX6XHD3IGDMG2Y2H3ZBKDO7AVCNFSM6AAAAABHNPKVQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBRGM3TENJVHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[dodexahedron]

It's pretty common in a lot of UI frameworks to expose both a coordinate pair (so Point, here) as well as the component coordinates, as ints, with the actual value being stored in the Point and the ints just retrieving that coordinate from the point for get and mutating the Point on set (it's immutable, so that means re-assignment - use the with { X = value; } method for that).

I'd suggest, to help with this sort of thing in general, and to force us to be consistent (plus for testing and other benefits), an IPositionable or otherwise appropriately named interface be created that has exactly those 3 properties, with both get and set accessors on all 3.

Implementations in types declaring the interface should store just the Point as a private field and the properties do the above operations.

We really need more interfaces, in general, for formality, consistency, testing, and consumer flexibility, without dependency on implementation.

[dodexahedron]

Oh also, a pretty important thing about immutable types as properties:

The get accessor for any property that is an immutable type should be readonly get instead of just get, so that the compiler will disallow attempts to write to the returned item - which is important because it's a copy, as properties cannot return by reference.

[tig]

See #3461

[tig]

Note, as part of

• Refactor MouseEvent and MouseEventEventArgs to simplify #3029

... we need to change MouseEvent to hold a Point

[dodexahedron]

Emphatic agree on that one. 👍