Unpräzise Namensgebung bei TRectF.Empty und TRectF.IsEmpty ?

[Rollo62]

Hallo zusammen,

ich stolpere gerade über einen Konflikt bei den IsEmpty Routinen, welche so definiert sind:

Delphi-Quellcode:

class function TRectF.Empty: TRectF;
begin
  Result := TRectF.Create(0,0,0,0);
end;

function TRectF.IsEmpty: Boolean;
begin
  Result := (Right <= Left) or (Bottom <= Top);
end;

Das Problem ist, dass ich TRectF als Speicher für separate Left,Top,Right,Bottom benutze, welche nicht unbedingt ein Rechteck aufspannen.
Also könnte RectF( 0, 0, 0, 50 ) sein, somit die Fläche IsEmpty: JA, aber die Variable IsEmpty: NEIN ( aus meiner Sicht ).

Als Argument dafür sehe ich, dass es die Funktion TRectF.Empty gibt, welche (0,0,0,0) definiert, also würde ich IsEmpty für (0,0,0,0) erwarten.

Für meinen angedachten Fall würde ich die Funktion IsZero vorsehen,
in ähnlicher Weise wie dies bei TPointF und Anderen vorhanden ist, bei TRectF aber nicht:

Delphi-Quellcode:

function TRectF_Helper.IsZero : Boolean;
begin
    Result := SameValue(Left, 0.0) and SameValue(Top, 0.0) and SameValue(Right, 0.0) and SameValue(Bottom, 0.0);
end;

Wie seht Ihr das, ist Empty / IsEmpty vielleicht ein gar nicht so präziser Name wie ich immer dachte ?
Oder sollte die Funktion IsEmpty vielleicht sogar ein Ergebnis ergänzt um IsZero zurückgeben ?

Vielleicht sollten die Funktionen auch einfach nur anders heißen, um präzise zu sein, wie EmptySpace und IsEmptySpace ?

Bin ich jetzt einfach nur zu pedantisch, oder gibt es ein gutes Argument für IsEmpty ?
Immerhin sagt "TRectF" ja implizit aus, dass es um die Fläche von Rechtecken geht.

Keine Angst, ich will hier keinen Feature-Request starten, ich möchte nur wissen, wie man den Unterschied Empty/Zero am besten im Namen oder Funktionsweise beschreiben würde
Immerhin benutze ich TRectF ja als Speicher für nicht-Flächen, somit etwas außerhalb der Spezifikationen ...

[Der schöne Günther]

Zitat von Rollo62:

dass ich TRectF als Speicher für separate Left,Top,Right,Bottom benutze, welche nicht unbedingt ein Rechteck aufspannen.
(...)
Immerhin benutze ich TRectF ja als Speicher für nicht-Flächen, somit außerhalb der Spezifikationen ...

Genau das ist doch der Punkt. Ist die Fläche leer? Ja. Gibt TRectF.Empty() eine leere Fläche zurück? Ja. Mit dem Code ist alles in Ordnung und die Namen passen auch.

Zweckentfremdest du TRectF für etwas anderes? Ja.

Mach dir doch deine eigene Struktur und benenne die Felder innen drin auch für das, was sie ausdrücken. Deinen bestehenden Code musst du auch nicht umschreiben, du kannst deiner eigenen Struktur doch eine Operator-Überladung verpassen, mit welcher sie implizit in ein TRectF konvertiert wird.

[Rollo62]

Zitat von Der schöne Günther:

Genau das ist doch der Punkt. Ist die Fläche leer? Ja. Gibt TRectF.Empty() eine leere Fläche zurück? Ja. Mit dem Code ist alles in Ordnung und die Namen passen auch.

Ja, das sehe ich auch so, allerdings sagt IsEmpty möglicherweise nicht deutlich genug, dass es NUR um die Fläche geht und nichts anderes, zumal Empty = (0,0,0,0) setzt.
Diesen Konflikt meine ich, speziell (0,0,0,0) deutet darauf hin, dass auch das IsZero gemeint sein könnte.

Zitat von Der schöne Günther:

Zweckentfremdest du TRectF für etwas anderes? Ja.

Genau, ich speichere dort die Insets, das sind mehr oder weniger Margins, weil das von anderen Libraries dafür genommen wird.
Im Prinzip finde ich das TRectF dafür in Ordnung, wegen Left / Top / Right / Bottom, obwohl es natürlich besser ein TMargins sein sollte.

Zitat von Der schöne Günther:

Mach dir doch deine eigene Struktur und benenne die Felder innen drin auch für das, was sie ausdrücken. Deinen bestehenden Code musst du auch nicht umschreiben, du kannst
deiner eigenen Struktur doch eine Operator-Überladung verpassen, mit welcher sie implizit in ein TRectF konvertiert wird.

Danke für die Vorschläge, meine Lösung ist es einen TRectF-Helper mit Zero / IsZero für das RectF anzulegen.
Damit komme ich klar.
Nach meiner Definition ist: Zero - es geht um 0,0,0,0 und Empty - es geht um Fläche.

Mir ging es mehr um die Konflikte mit der Namensgebung.
Würdest Du im oben genannten Fall auf z.B. TMargins (ist aber eine Klasse meines Wissens) oder noch besser ein TInsets Record umsteigen,
selbst wenn es auf TRectF ausgelegt ist ?

In diesem Fall kommt das aus einer externen Library, aber ich selber missbrauche auch gerne die Delphi Basic-Typen für solche naheliegende Fälle.

Das ist meine Frage: "Missbraucht" Ihr solche Basistypen (TRect, TPoint, TSize, ...) auch manchmal, oder seid ihr IMMER strikt Namenskonform ?

Das richtige Festlegen von Namen ist manchmal eine Qual

[Neutral General]

Man kann mal was missbrauchen, aber gerade wenn der Typ dann nicht ganz den Anforderungen entspricht und letztendlich nur ein Record mit 4 Feldern ist, würde ich eindeutig für nen eigenen Typ sprechen.
Du hast wahrscheinlich so viel mehr Zeit jetzt verschwendet (allein schon mit dem Thread hier) als das schreiben eines eigenen Typs gedauert hätte.

[Rollo62]

Ja, aber wie gesagt, es kommt von Extern.
Dann würde ich intern und extern verschiedene Typen verwenden und müsste extra noch konvertieren.
Da finde ich die Ergänzung mit IsZero für mich sinnvoller, auch weil das Problem eventuell mal auch woanders auftreten kann.

Damit könnte ich dann immer eindeutig definieren, was ich gerade brauche: IsEmpty oder IsZero.

Ich finde diese Ergänzung einigermaßen natürlich, insbesondere auch weil es das bei anderen Typen so gibt, z.B. TPoint.

Falls ich spezielle Typen brauche, dann lege ich die in der Regel auch an.
Aber wenn es einen zu 99% gut passenden Basistypen gibt, auch vom Namen her, sollte man den nicht einfach nehmen ?
Ursprünglich bin ich von 100% passend ausgegangen, das war leider falsch,
aber werden bei ganz neu angelegten Typen die Fehlerraten nicht noch viel heftiger werden als bei den jahrzehntelang perfekt gewarteten Typen ?

[himitsu]

implizites Type-Casting : https://docwiki.embarcadero.com/RADS...toren_(Delphi)
VariableMitInternemTyp := VariableMitExternemTyp;

oder via Record-Helper ein passenderes "IstLeer" hinzufügen

oder kapseln

Delphi-Quellcode:

type
  TMyRecord = record
  {private}
    Intern: TRect;
    function GetWidth: Integer;
    procedure SetWidth(Value : Integer);
    ...
  {public}
    property Top:    Integer read Intern.Top  write Intern.Top;
    property Left:   Integer read Intern.Left write Intern.Left;
    property Width:  Integer read GetWidth write SetWidth;
    property Height: Integer read GetHeight write SetHeight;
  end;

Was ist "Extern"?
Wenn es eine DLL ist, dann verbietet dir niemand intern einen anderen/eigenen Typen zu benutzen (so lange er von den Daten/Feldern her identisch/kompatibel ist)

[Rollo62]

Zitat von himitsu:

oder via Record-Helper ein passenderes "IstLeer" hinzufügen

Dankesehr, wie gesagt das mache ich mit einem Record-Helper als "IsZero"

Mir ging es eher um die Frage inwieweit man solche Basistypen "missbrauchen" sollte und ob, wann und wo Ihr das auch mal macht.

Der Wrapper, den Du vorschlägst, wäre ja für diesem Fall der Worst-Case, aus meiner Sicht, nur um L,T,R,B zu kapseln ( dann doppelt gekapselt ).
Viel Overhead bei Null Nutzen.

Ich nutze schonmal gerne die Basictypen TRect, TRectF, TPoint, TPointF, TSize, ... um ähnliche Dinge zu kapseln.

Bisher war mit der Unterschied IsEmpty und IsZero nicht so bewusst geworden.

[himitsu]

Wenn möglich verwende ich vorzugsweise Typen der StandardUnits des Delphi.
(von Typen aus mitgelieferten Units, ala INDY, nehme ich aber zunehmend Abstand)

Auch wenn es um neuere Typen geht, in Codes/Komponenten auch für ältere Delphis,
da dann natürlich mit Fallback. https://www.delphipraxis.net/213082-...ml#post1522679

[Rollo62]

Genau das meine ich.

[Neutral General]

Zitat von Rollo62:

Zitat von himitsu:

oder via Record-Helper ein passenderes "IstLeer" hinzufügen

Mir ging es eher um die Frage inwieweit man solche Basistypen "missbrauchen" sollte und ob, wann und wo Ihr das auch mal macht.

Ich denke himitsu und ich waren da relativ eindeutig, aber da du deine Lösung immer noch stark verteidigst weiß ich nicht was noch groß dazu gesagt werden soll.
Es sei denn du wartest noch auf jemanden der dir Recht gibt