Swift legt traditionell großen Wert auf die Klarheit der Syntax und ermöglicht es, eigene Operatoren (Operatorüberladung) zu erstellen, einschließlich neuer Symbole und sogar Schlüsselwörter. Dies erweitert die Möglichkeiten von DSL und macht den Code sehr ausdrucksstark.
Ohne Verständnis der Prinzipien der Operatorenkonfiguration kann man unklare, schlecht lesbare und schwer wartbare Codes erhalten. Eine falsch gewählte Priorität oder Assoziativität kann zu unerwarteten Ergebnissen führen. Der Compiler erlaubt die Erstellung von ziemlich "gefährlichen" Ausdrücken, wenn keine Einschränkungen angegeben werden.
Neue infix, prefix, postfix Operatoren können deklariert werden, ihre Prioritäten und Anwendungsbereiche können festgelegt werden. Beispiel:
infix operator ~> : AdditionPrecedence func ~> (lhs: Int, rhs: Int) -> Int { return lhs * 10 + rhs } let x = 2 ~> 3 // 23
Für benutzerdefinierte Prioritäten muss deklariert werden:
precedencegroup MyPrecedence { associativity: left higherThan: AdditionPrecedence } infix operator *** : MyPrecedence
Wichtige Merkmale:
Ist es notwendig, sowohl die Funktion als auch die Operatorenkonfiguration zu implementieren?
Ja, wenn man einen Operator deklariert, muss man die entsprechende Funktion implementieren – andernfalls wird ein Compilerfehler auftreten. Die Funktionen haben eine Signatur, die mit der des Operators übereinstimmt.
Wie wählt man die richtige precedencegroup und wie beeinflussen Gruppen die Reihenfolge der Berechnungen?
Die precedencegroup legt die Berechnungspriorität und Assoziativität für infix-Operatoren fest. Eine falsche Wahl der Gruppe kann zu unerwarteten Ergebnissen in Ausdrücken mit mehreren Operatoren führen (z. B. Multiplikation/Addition und Ihrem benutzerdefinierten Operator).
Kann man einen benutzerdefinierten Operator mit einem Textnamen deklarieren?
Nein, benutzerdefinierte Operatoren sind nur über spezielle Symbole oder Sequenzen verfügbar, die durch die Syntax von Swift definiert sind. Textliche Standardnamen sind für die Deklaration als Operator nicht erlaubt.
Im Projekt wurden die Operatoren <<< und >>> für seltsame Umwandlungen von Sammlungen deklariert, ohne Priorität, Assoziativität und Dokumentation zu beschreiben. Neue Mitarbeiter verstanden nicht, was sie taten und in welcher Reihenfolge die Ausdrücke berechnet wurden.
Vorteile:
Nachteile:
Im Projekt wurde der benutzerdefinierte Operator => für die deklarative Erstellung einer chainable Pipeline (z. B. im UI-Builder) verwendet, mit klarer Beschreibung der Priorität und dokumentierter Implementierung. Jeder Entwickler verstand, was er tat und wie es verwendet wurde.
Vorteile:
Nachteile: