Maßeinheiten als Typen

[Ghostwalker]

Das mit der direkten Zuweisung von verschiedenen Maßeinheiten ist eher Kontraproduktiv. Den dann wärs ja wieder möglich, bei Verwendung als Methoden-Parameter, bei Gramm, Kilogramm zu übergeben.

Das läst sich aber umgehen, in dem man statt Implizierter Typumwandlung die Explizite Variante wählt.

Was mich allerdings irretiert ist, wo der Vorteil liegen soll, das ganze in einem Typ zu handhaben.

@p80286
siehe 1 Post und Verweis auf anderen Thread

Ursprünglich wollte ich für jede Maßeinheit (als Beispiel hab ich Gewichte genommen) einen eigenen eigenen
Record definieren mit entsprechenden Operatoren und Convertierungen. Im anderen Thread ging es darum, ob man
entsprechende Unittests generieren kann. Dabei kamm die Frage auf, ob das wirklich das beste Design ist (also
einzelne Typen für Maßeinheiten), da es doch recht aufwendig ist. Da das ganze mit der Unittest-Frage nur indirekt zu tun hab, hab ich das ganze mal abgekapselt.

[TiGü]

Zitat von Ghostwalker:

Ursprünglich wollte ich für jede Maßeinheit (als Beispiel hab ich Gewichte genommen) einen eigenen eigenen
Record definieren mit entsprechenden Operatoren und Convertierungen.

Das ist ja auch vollkommen okay.
Du musst nur verstehen das Kilogramm, Gramm, Mikrogramm, Nanogramm K E I N E verschiedenen Maßeinheiten sind.
Es ist immer ein und dieselbe Maßeinheit mit verschiedenen Vorsätzen.
Ich wiege gleichzeitig 100 kg = 100000 g = 100000000000000 ng.
Das kann man mit einem einzigen Typen abbilden.

[Jumpy]

Ich hab gestern zufällig einen Vortrag (Java, sorry) gehört über eine "JSR-354 Money and Currency API".
Grundprinzip war in etwa, das Geld jeweils aus einem Betrag und einer Währung besteht und alles jeweils Objekte sind, mit diversen Eigenschaften und Methoden. Dazu gibt es Umrechnungsobjekte von Währungen usw.

Was ich damit sagen will: Wenn man es schon kompliziert und ausführlich machen will, mit viel Overhead, dann aber auch alles richtig als Objekte abgebildet mit Typsicherheit usw. (auch wenn Delphi nicht Java ist, kann man sich da ja was abgucken).

[Rollo62]

Zitat:

Es ist immer ein und dieselbe Maßeinheit mit verschiedenen Vorsätzen.

Jein, das stimmt zwar in den meisten Fällen.
Also Kg, ng, gr, m, cm, dm sind nur verschiedene Faktoren, das ist leicht.

Aber es gibt auch Ausreisser, z.B. bei Temperatur (°C, °F, °K),
das muss man mit Offset und Faktor arbeiten.

Oder bei Winkeln und Längen in diversen Darstellungsformen, z.B. der worst case ist wohl in USA mit der grässlichen inch-feet Darstellung und Brüchen derselben.


Rollo

[Schokohase]

@Rollo62

Egal wie komplex die Umrechung ist, die Bedeutung bleibt aber immer dieselbe, egal in welcher Dimension ich diese Einheit darstelle/angebe.

Es wird nicht heißer oder kälter wenn ich die Temperatur(-Differenz) in Celsius, Kelvin oder Fahrenheit angebe.

Es wird nicht schwerer oder leichter wenn ich das Gewicht in Kilogramm, Tonnen oder Mikrogramm angebe.

Der TE hat es aber bislang nicht geschafft auch nur ansatzweise eine Begründung zu liefern, warum er diese Aufsplittung einer Einheit in unterschiedliche Dimensions-Typen als nötig erachtet. Es kommt nur ein "ja, wenn man das mal braucht".

[JasonDX]

Zitat von Rollo62:

Zitat:

Es ist immer ein und dieselbe Maßeinheit mit verschiedenen Vorsätzen.

Jein, das stimmt zwar in den meisten Fällen.
Also Kg, ng, gr, m, cm, dm sind nur verschiedene Faktoren, das ist leicht.

Aber es gibt auch Ausreisser, z.B. bei Temperatur (°C, °F, °K),
das muss man mit Offset und Faktor arbeiten.

Oder bei Winkeln und Längen in diversen Darstellungsformen, z.B. der worst case ist wohl in USA mit der grässlichen inch-feet Darstellung und Brüchen derselben.

Es ist aber immer die selbe physikalische Größe. Deswegen glaube ich dass die weiter oben vorgeschlagene Möglichkeit, orientiert an System.TimeSpan.TTimeSpan, die sinnvollste Lösung ist: Sie dokumentiert um welche Physikalische Größes es sich handelt (Und garantiert dass nicht Sekunden statt Gramm übergeben werden), inklusive der exakten Maßeinheit (es wird vermieden dass ein Wert als "meter" angegeben, aber als "millimeter" interpretiert wird), und erlaubt flexible Konvertierungen (Bei Gewicht kann dies z.B. auch Pfund etc. beinhalten, bei Geschwindigkeit m/s, kmh und mph, und zwischen Kelvin, Celsius und Fahrenheit zu konvertieren ist auch kein Problem).
Einzig Operatoren würde ich außen vor lassen. Addition und Subtraktion sind vllt. noch machbar, aber bei Multiplikation&Division wirds schwierig: Bspw. muss das Multiplikationsergebnis aus Spannung und Stromfluss vom Divisionsergebnis aus Drehmoment durch Zeit subtrahierbar sein.

Guava macht das ganze übrigens ähnlich.

[TiGü]

Plot Twist: Das eigentliche Grundproblem ist etwas ganz anderes und kann mit drei Zeilen erschlagen werden!

[Rollo62]

Natürlich ist es die gleiche Größe, das schreibe ich ja schon ganz unten.

Aber der Unterschied kann sein ob diese in einer Variablen gespeichert werden kann, oder ob ich mehrere brauche um alle Aspekte abzudecken.

Wenn ich es nur z.B. in Double speichere können dabei Informationenen verloren gehen, wie z.B. beim Winkel welcher Quadrant, o.ä.

Rollo

[Ghostwalker]

@Schokohase

Mein Post bezog sich insbesondere auf diese Aussage:

Zitat von TiGü:

Du musst nur verstehen das Kilogramm, Gramm, Mikrogramm, Nanogramm K E I N E verschiedenen Maßeinheiten sind.

und die ist schlicht [Zensiert].

Klar sind 1000g = 1Kg [B]ABER] 1000g <> 1000Kg <> 1000m <> 1000V

[TiGü]

Zitat von Ghostwalker:

@Schokohase

Mein Post bezog sich insbesondere auf diese Aussage:

Zitat von TiGü:

Du musst nur verstehen das Kilogramm, Gramm, Mikrogramm, Nanogramm K E I N E verschiedenen Maßeinheiten sind.

und die ist schlicht [Zensiert].

Klar sind 1000g = 1Kg [B]ABER] 1000g <> 1000Kg <> 1000m <> 1000V

Man könnte auch sagen [zensiert] = richtig!

Sowas wie 1000g <> 1000kg zog niemand in Zweifel, da 1000 g ungleich zu 1000000 g ist (bzw. 1 kg ungleich 1000 kg).
Du denkst - oder es kommt uns allen nur so vor - das die MaßEINHEIT Gramm und Kilogramm zwei verschiedene Paar Schuhe sind.
Das ist aber nicht so. Das eine Schuh-Paar ist nur "größer", aber sonst das selbe (!) Modell.

Einen gängigen Weg, wie man das mit Operatoren im Record erschlagen kann, hast du im Laufe der letzten Seiten vielfach aufgezeigt bekommen.