Laraus V3 RC1 - Frage zu "+=" und "-="

[MmVisual]

Ein "i += 1;" geht ja seit geraumer Zeit.

Könnt ihr das auch für Set's mit rein nehmen so dass dies auch geht?:

Code: Alles auswählen

Var sp: TSpeedButton;
  If sp.Down Then
    sp.Font.Style += [fsBold]
  else sp.Font.Style -= [fsBold];

Diese Schreibweise geht ohne Compile Fehler:

Code: Alles auswählen

  If sp.Down Then
    sp.Font.Style := sp.Font.Style + [fsBold]
  else sp.Font.Style := sp.Font.Style - [fsBold];

Vielen Dank an das Lazarus/FPC Team.

Grüße Markus

[Warf]

Es geht für sets:

Code: Alles auswählen

{$ScopedEnums On}
type
  TTest = (A, B, C);
  TTestSet = set of TTest;

var
  s: TTestSet;
begin
  s := [];
  s += [TTest.A];
  s -= [TTest.B];
  s *= [TTest.C];
end.

Es geht nur nicht für Properties, was in deinem Beispiel das Problem ist:

Code: Alles auswählen

type
  TTest = class
    FA: Integer;
    property A: Integer read FA write FA;
  end;

var
  t: TTest;
begin
  t:=TTest.Create;
  t.A += 1; // Error
end. 

[MmVisual]

Hm, ja klingt irgendwie plausiebel.

Dann müsste der FPC erkennen dass das Read-Modify-Write auf einem Property ausgeführt werden soll und nicht nur in einer RAM Speicheradresse.
Und einen Fehler erzeugen wenn das Property nicht beides, also "read" und "write" besitzt.

[af0815]

Gab es nicht dazu eine Diskussion im englischen Forum ?! Es gibt bei inc() etc. dieselben Einschränkungen. Bei Properties kann ja auch ein Getter bzw. Setter dahinterstehen, nicht nur ein Verweis auf eine SPeicherstelle.

[MmVisual]

Aus FPC Programmierer sicht ist es Logisch, dass so etwas nur schwer um zu setzen ist.

Als Anwender von Lazarus erst einmal irgendwie unverständlich warum das eine geht und das andere nicht. Als Anwender sieht man nicht auf den ersten Blick warum es nicht geht und denkt sich ob es noch ein Bug sein könnte.

Mein Vorschlag wäre dass der Compiler bei Properties eine Fehlermeldung mit dem Text generiert:
"+= not allowed on properties"
(oder ähnlich)

[m.fuchs]

Ich verstehe den Sinn dieser Schreibweise in Pascal nicht. Wer so etwas braucht soll bitte C nehmen.
Was ist da aus deiner Sicht der Vorteil?

[MmVisual]

Ganz einfach: Ich mag die schreibweise. Viele andere mögen diese auch, sogar welche aus dem FPC Team mögen diese Schreibweise, sonst wäre es ja nicht in das FPC mit rein gekommen.

Ein

Code: Alles auswählen

I += 1;
I := l + 1;

Bei der ersten Zeile sieht man sofort dass es ein Increment sein soll.
Bei der zweiten Zeile muss man schon genau hinschauen dass es 2 unterschiedliche Variablen sind.

Daher bin ich der Meinung, dass ein "+=" den Code einfacher lesbar macht, auch wenn man sich zu Anfang erst einmal daran gewöhnen muss.

[KoBraSoft]

Wer so etwas braucht soll bitte C nehmen.

Nö, der sollte schon bei Pascal bleiben
Die Zeit die man beim tippen länger braucht, holt man später beim Lesen locker herein.

Code: Alles auswählen

I := l + 1;

I und l als Variablennamen nehmen ist keine gute Idee.

[MmVisual]

Niemand wird dazu gezwungen ein "+=" zu nutzen, wer das nicht mag kann nach wie vor die alte Schreibweise nutzen.

Die eigenen Vorlieben sind jetzt ja auch nicht das Thema in diesem Threat, sondern die Frage warum das mal geht und mal nicht und das wurde ja bereits geklärt.

[Warf]

Ich verstehe den Sinn dieser Schreibweise in Pascal nicht. Wer so etwas braucht soll bitte C nehmen.
Was ist da aus deiner Sicht der Vorteil?

Relativ einfach, es ist
1. Weniger zu tippen
2. Einfacher zu lesen, denn du weist beereits schon nach dem zweiten Zeichen was hier passiert
3. Weniger Fehleranfällig, denn beim tippen einer Variable können tippfehler passieren

Beispiel:

Code: Alles auswählen

ClientWidth += Button1.Width

Ganz klar, hier wir wird die weite um die des Buttons vergrößert. Einfach zu tippen und einfach zu verstehen.

Code: Alles auswählen

ClientWidth := Button1.Width + ClientWidth

Hier erkennst du erst wenn du die ganze Expression gelesen hast das es sich um einen simplen inkrement handelt. Selbst im best case, wenn du die Increment variable direkt nach links schreibst:

Code: Alles auswählen

ClientWidth := ClientWidth + Button1.Width

Musst du immernoch mental bis zum 4ten token lesen bevor du verstehst was passiert. Es ist schlicht weg mehr mentaler Aufwand. Nicht viel, aber jedes bisschen kostet Zeit, Nerven und Energie.

Gleichzeitig, wenn du mehr tuen musst um etwas zu erreichen gibt es auch mehr Gelegenheiten Fehler zu machen. Wenn du z.B. Lazarus mit Autocomplete verwendest, passiert es manchmal das du das falsche completest, und ClientWidth ist erstaunlich nah an ClientHight. Und lustigerweise ist mir das sogar grade genau beim Tippen passiert, das ich beim Beispiel beim zweiten mal ausversehen ClientHight hingeschrieben hab ganz ohne Autocorrect, weil ich irgendwie ClientHight im Kopf hatte.
Fehler passieren, und gutes Sprachdesign sollte möglichst versuchen alle Fehlerquellen zu vermeiden.

Außerdem, noch ein Bonuspunkt, du brauchst keine Klammern:

Code: Alles auswählen

X *= 2;
// Willst du ändern zu
x *= 2 + ScalingFactor;

Durch die *= schreibweise kannst dus einfach hinten dran hängen, bei normaler arithmetik musst du klammern, was zwar natürlich kein großer Aufwand ist, aber dennoch eine Fehlerquelle, und ich würde Lügen wenn ich sagen würde das ich, z.B. wenn ich müde war, noch nie Klammern vergessen habe.

Ich sehe tatsächlich absolut keinen Nachteil darin.

[Warf]

Gab es nicht dazu eine Diskussion im englischen Forum ?! Es gibt bei inc() etc. dieselben Einschränkungen. Bei Properties kann ja auch ein Getter bzw. Setter dahinterstehen, nicht nur ein Verweis auf eine SPeicherstelle.

Hier ist aber der Punkt warum ich es nicht verstehe, += ist kein eigener inplace operator (wie z.B. C++ indem man es für Performanceoptimierungen als Inplace operation durchführen kann), Inc schon. x += y ist tatsächlich nix anderes als x := x + y;
Das kann man sehr schön mit den Management Operatoren betrachten:

Code: Alles auswählen

{$ModeSwitch advancedrecords}

uses SysUtils;

type
  TTest = record
    Name: String;
    class operator Copy(constref src: TTest; var dst: TTest);
    class operator +(a: TTest; b: Integer): TTest;
  end;

class operator TTest.Copy(constref src: TTest; var dst: TTest);
begin
  dst.Name += ' := ' + src.Name;
end;

class operator TTest.+(a: TTest; b: Integer): TTest;
begin
  Result.Name := a.Name + ' + ' + b.ToString;
end;

var
  t: TTest;
begin
  t.Name := 't';
  t += 42;
  WriteLn(t.Name);
end.

Ergebnis:

Code: Alles auswählen

t := t + 42

Semantisch ist es also komplett equivalent zu einem normalen Assignment von einem Aufruf der Operatorfunktion mit t und 42 als Argument, also im grunde was hier passiert ist

Code: Alles auswählen

t := Add(t, 42)

Wobei Add intern die + Operator funktion wäre.

Und das funktioniert natürlich genauso mit r/w Properties wie es mit Variablen funktioniert. Semantisch gibt es also keinen Grund warum das nicht funktionieren sollte. Es ist vermutlich einfach nur eine Technische Limitierung durch die implementation des FPC.

Im unterschied dazu ist Inc eine Inplace funktion, also Inc(i, 42) wird übersetzt zu der solo ASM Instruktion addl $42,-8(%rbp) wobei "-8(%rbp)" die addresse der Variable auf dem Stack ist (i in meinem Beispiel). Verglichen mit i += 42 ergibt das folgende:

Code: Alles auswählen

        movl    %edi,-8(%rbp)
        movl    -8(%rbp),%eax
        leal    42(%eax),%eax
        movl    %eax,-8(%rbp)

Wie im beispiel oben wird hier erst einmal das Temporäre Ergebnis von i + 42 ausgerechnet, bevor das wieder in i geschrieben wird.

Von daher macht es Sinn das Inc auf Instruktionen nicht geht, aber es macht keinen Sinn das += nicht geht

[m.fuchs]

Relativ einfach, es ist
1. Weniger zu tippen

Und bei dem Argument bin ich schon raus. Denn dann bleibt es bei meiner Empfehlung: zu C wechseln.

Über den Rest muss ich noch einmal nachdenken.

Der Nachteil ist halt, dass diese verkürzten Operatoren nicht auf mathematischen Operatoren beruhen. Das macht es ein bisschen unsauberer, ist aber natürlich auch eine Gewöhnungsfrage - das sehe ich ein.

Ein

Code: Alles auswählen

I += 1;
I := l + 1;

Bei der ersten Zeile sieht man sofort dass es ein Increment sein soll. Bei der zweiten Zeile muss man schon genau hinschauen dass es 2 unterschiedliche Variablen sind.

Wer solche Variablennamen benutzt, hat Probleme aber auch ein bisschen verdient.

[Warf]

Und bei dem Argument bin ich schon raus. Denn dann bleibt es bei meiner Empfehlung: zu C wechseln.

Ja weniger Tippaufwand ist für sich genommen kein gutes Argument, und ich finde selbst das oftmals guter Code durch Faulheit schlecht wird, z.B. wenn Namen soweit verkürzt werden das niemand mehr versteht was das heißen soll (was hat "val" noch mit "String in Ordinalwert Umwandeln" zu tun, um ein Beispiel aus Pascal zu nehmen).

Aber wenn alles andere gleich ist, dann tipp ich lieber weniger als mehr. Ich schreibe ja auch lieber a + b als 'a plus b', und das ist nix anderes als eine Faulheitskonvention die aus der Mathematik übernommen wurde.

Der Nachteil ist halt, dass diese verkürzten Operatoren nicht auf mathematischen Operatoren beruhen. Das macht es ein bisschen unsauberer, ist aber natürlich auch eine Gewöhnungsfrage - das sehe ich ein.

Bei mir damals auf der Uni wars sowieso immer schon ein Witz das wir Informatiker die Mathematische Notation misbrauchen weil wir z.B. die Natürlichen Zahlen N mit 0 anfangen lassen, wobei die Mathematiker das explizit N0 nennen.
Ein bisschen schwund ist immer oder so

[MmVisual]

Gute Programmierer sind schon immer Tipp-Faul gewesen
Die programmieren so kompakt und effizient, dass der Compiler daraus einen superschnellen Code erzeugen kann und zudem weniger RAM verbraucht.

Guter Tipp mit dem Inc(x) ... dass da ein optimierter Assembler-Befehl raus kommt.

Anderseits:
Bei einem i += 5; sollte der FPC auch so klug sein und den optimierten Assembler Befehl einseztzen und kein Read-Modify-Write.
Als Programmschreiber würde ich zumindest davon ausgehen, dass solche Optimierungen der Compiler kann.

[m.fuchs]

Gute Programmierer sind schon immer Tipp-Faul gewesen

Äh nein, gute Programmierer erkennt man daran, dass der Code lesbar ist. Und das ist oftmals diametral zur Tippfaulheit