"forward" property Felder/getter/setter?

[mse]

Durch implizite Typumwandlungen gibt es schwierig zu erkennende Fehler in Ausdrücken.

Mir fällt eigentlich kein Beispiel ein, in der die Umwandlung von einem schmäleren in einen "breiteren" Datentyp zu schwierig zu erkennenden Fehlern führt. Die Gegenrichtung ist auch jetzt entweder gar nicht implizit möglich (real->integer), passiert nie innerhalb der Berechnung von Ausdrücken, sondern nur bei Zuweisungen (da sollte sich der Programmierer aber wirklich im Klaren darüber sein, welchen Wert er welcher Variablen zuweist), oder löst, zumindest in Delphi, eine Compilerwarnung aus (z.B. integer -> Byte oder char -> ansichar)

Z.B. Bitmanipulationen mit Masken und shift. Da MSElang explizite Datengrössen bevorzugt (int8, int16, int32, int64, card8, card16..., string8, string16, string32, char8...) wäre es konsequent dies auch in Ausdrücken zu tun. Aber wie gesagt, ich muss noch mehr ausprobieren.

[m.fuchs]

1. Zuweisungen in Vergleichen wären manchmal sehr nützlich.

Warum?

Weil es einem manchmal ersparen würde, den exakt gleichen Programmcode zwei mal zu schreiben.

Wie das? Hast du dafür bitte einmal ein Beispiel?

Es ist, wie ich oben begründet habe, BESSER leserlich: Bei ifthen stehen die Bedingung und die beiden Alternativausdrücke gleichberechtigt auf der gleichen Ebene als Funktionsparameter nebeneinander, während der ternäre Operator die Semantik des Befehls unmittelbar sichtbar macht.

Ich habe nicht gesagt dass ifthen lesbarer ist, das würde ich in vielen Fällen auch nicht verwenden.

Dass bei Verwendung von IfThen immer beide Zweige ausgewertet werden, disqualifiziert das Konstrukt meines Erachtens komplett, ich verwende das prinzipiell gar nicht mehr, nachdem ich schon mehrmals unbedachter Weise über Laufzeitfehler wie den im oberen Post aufgezeigten gestolpert bin. Das ist eine unnötige Fehlerquelle.

Richtig, deswegen das ganze in eine eigene Funktion auslagern. Auf solche Konstrukte kann man dann ganz verzichten. Zumal sie keinen Informationsgewinn bieten.

[pluto]

1. Zuweisungen in Vergleichen wären manchmal sehr nützlich.

Führt aber zu Fehler Quellen.

Was du brauchst ist ein Basistyp, der alle verwendeten Datentypen beschreibt und spezialisierte Nachkommen, welche die Datentypen implementieren.

Ja, so hatte ich es auch schon mal umgesetzt.

[braunbär]

1. Zuweisungen in Vergleichen wären manchmal sehr nützlich.

Führt aber zu Fehler Quellen.

Programmieren ist eine einzige riesige Fehlerquelle
Und der ternäre Operator würde keine Zuweisungen in Vergleichen ermöglichen - oder kannst du dafür ein Beispiel bringen?

Wie das? Hast du dafür bitte einmal ein Beispiel?

Schreibe einmal das folgende in normaler Pascal Syntax, ohne irgend etwas zwei mal zu machen.

Code: Alles auswählen

 
while (l := length(s)) < 10 do 
     insert('x', s, l div 2)
 

Es geht zwar, mit Hilfe eines repeat until false, mit einem break in der Mitte, aber so finde ich es viel eleganter. repeat wirkt da m.E. leicht irreführend, weil das Programm in Wirklichkeit einer While-Logik folgt.

Ich habe nicht gesagt dass ifthen lesbarer ist, das würde ich in vielen Fällen auch nicht verwenden.

Lesbarkeit ist halt etwas reichlich subjektives. Ich finde Statements mit dem ternären Operator sehr gut lesbar, übersichtlich und dabei kompakt. Aber ich programmiere auch viel in autohotkey (das in anderer Hinsicht nicht sonderlich übersichtlich ist), deshalb bin ich diese Schreibweise gewöhnt.
Gefällt dir das besser:

Code: Alles auswählen

 
ch := if length(s)>0 then  s[1] else '  ';
 

Richtig, deswegen das ganze in eine eigene Funktion auslagern.

Warum sollte man für eine einfache if-Abfrage mit je einer Zuweisung im then- und im else Zweig eine eigene Funktion machen? Meinst du wirklich, dass so etwas zur Lesbarkeit des Codes beiträgt?
Mit dem ternären Operator wird das zum einem einfachen Einzeiler, und das ist sicher nicht schlechter als eine separate Funktion, die man erst suchen muss.

[m.fuchs]

Damit mse hier auch weiter ungestört Vor- und Nachteile seiner Sprache diskutieren kann, ist der Teil mit der Auslagerung in Funktion hierher verschoben: viewtopic.php?f=9&t=10863