Interessanterweise ist das für mich eben gerade ein Beispiel von klarem Code.
Also in meinen Augen sollte ein Datentyp mit dem Namen 'TDate' ein Datum enthalten, sonst nichts. Analog sollte ein 'TTime' eine Uhrzeit repräsentieren. Alles andere ist verwirrend.
Nach deiner Sichtweise könnten wir auch mit einem einzigen Zahlentyp aufwarten: 'TNumber', denn es ist ja die Schuld des Programmierers, wenn der Code dadurch nicht klar genug ist. Ich kann deine Sichtweise nachvollziehen, aber die Schlußfolgerung ist
imho falsch.
diverse Bibliotheken definieren sich ihre eigenen Stringtypnamen, die auch "identisch" mit den normalen sind. Oder wir alle haben schonmal ne MeineUnitException = class(
Exception) ohne mehr dran verwendet, oder?
Diese Datentypen sind ja auch von der Bedeutung her identisch
Zitat:
Und das ist dann eben "Schuld" des Programmierers. Da ist der Wert extra schon als ''TDate'' deklariert, und der Kerl weist auch ne Uhrzeit zu...
Unglaublich. Bei richtigen Programmiersprachen meckert hier der Compiler. Merkste was?
Ich verlange von meinen Datentypnamen, das das draufsteht, was drin ist. Nicht mehr und nicht weniger.
TDate, TTime und TDateTime sollten nicht zuweisungskompatibel sein, denn ein TDateTime ist genaugenommen ein genauer Zeitpunkt (innerhalb der bekannten Grenzen), während ein TDate einfach nur ein Datum und TTime nur eine Zeit darstellen sollte.
Desweiteren ist bei diesem Datentyp nicht zu vermitteln, wie die Differenz zwischen zwei Zeitpunkten wieder ein Zeitpunkt sein kann, das ist bescheuert und schlicht und ergreifend falsch. Genauso hirnrissig wie z.B. die Differenz zwischen zwei Temperaturangaben wieder als Temperatur anzugeben. Zwischen 5°C und 20°C liegen eben nicht 15°C sondern 15 K.
Delphi halt. Pragmatik und zum-frickeln-einladend-praktisch kommt vor
OOP. Das macht den jedoch Charme der Sprache aus.