Spatial_oM: Should IElement2D interface provide that outline is non-self-intersecting?

[LMarkowski]

Some of IElement2D methods don't ensure that the result outlines are non-self-intersecting and therefore don't warn the user if so.
I am wondering if the check and the warning could happen in the interface (e.g. ISetOutlineElements1D) method (which would mean that IElement2D ensures non-self-interesecting) or rather in class specific (SetOutlineElements1D) methods.
First approach would limit the code redundancy but maybe some IElements2D need to be self intersecting?

Raising an issue as it may concern many disciplines.
What do you think?
@pawelbaran @al-fisher @IsakNaslundBh @rwemay @FraserGreenroyd

[FraserGreenroyd]

I've converted this to a discussion for now until a tangible issue is found.

I would say, we have an outstanding issue on Test_Toolkit to detect objects which don't implement required interface methods raised previously, would that do as you're describing? This one here. Not entirely sure I understand the question though so this might not be relevant.

[LMarkowski]

I've converted this to a discussion

Oh, cool. I did not know that there was such an option 😮,

We actually talked that one through on the stand-up today. I'll brief it in another comment so it won't get lost in replies.

[LMarkowski]

Brief summary of findings from the call:

• we shouldn't (mustn't) prohibit IElement2D from being self-intersecting
• check and warning could take place in the setter methods
• IElement methods should be able to return incorrect results (with warning and pointer to a fixer method more than welcome)
• it is a part of a broader theme of dividing pre-checks, computing and post-checks

@al-fisher @IsakNaslundBh please, correct me if I'm wrong or forgot about something 🙂

[al-fisher]

No, I think this looks good to me.