Eben genau solche Beispiele. Zum Beispiel was du in Delphi hättest machen müssen, aber durch entsprechende Features (also Traits, Duck Typing, Type Inference, etc.) in einer anderen Sprache übersichtlicher oder einfacher hinbekommen hast.
OK. Fangen wir mal mit Type Inference an. Wie sehen anonyme Funktionen in Delphi aus (Beispiel aus der Doku)?
Delphi-Quellcode:
type
TFuncOfInt = reference to function(x: Integer): Integer;
function MakeAdder(y: Integer): TFuncOfInt;
begin
Result := function(x: Integer)
begin
Result := x + y;
end;
end;
Bitte was? Eigentlich ist das Konzept auch dazu gedacht, Code kürzer und pregnanter schreiben zu können. Aber das ist ja mal gelinde gesagt größtenteils Code Noise. Mit Inferer könnte das ganze logisch völlig äquivalent (und nach wie vor typsicher) z.B. so aussehen:
Delphi-Quellcode:
function MakeAdder(y: Integer): Integer => Integer;
begin
Result := x => x + y;
end;
Weiter zum Thema AOP. Damit kann ich z.B. mit weniger als 10 Zeilen Code an einer gebündelten Stelle einen kompletten Call Tree Logger implementieren, der z.B. JEDEN Methodencall loggt. Das ganze ist auch wunderbarst optional einkompilierbar, d.h. in der Production-Version ist der Code einfach nicht drin. Ansatzweise sähe das so aus (AspectJ):
Code:
public aspect TraceCalls {
pointcut aCall : call(* *(..));
before() : aCall() {
System.out.println(thisJoinPoint);
}
}
Das einzige was mir da in Delphi bleibt, ist in JEDER Methode einen Log-Aufruf zu implementieren und am besten noch mit ifdefs zu umschließen, damit das ganze auch optional reinkompiliert werden kann. ODer ich brauche ein special-prupose Logging-Tool, das den Code entsprechend instrumentieren kann. Muss ich noch viel mehr dazu sagen?
Weiter zum Thema Traits. Traits sind enorm vielseitig einsetzbar, und deren Mächtigkeit habe ich selbst glaube ich auch noch nicht vollumfänglich erfasst. z.B. kann man damit Multiple-Inheritance-ähnliche Dinge machen, allerdings mit deutlich weniger Brainfuck. Man kann auch einfach beliebige Funktionalität an beliebige Objekte drankleben. z.B. könnte man damit folgendes implementieren (gewürzt mit Duck Typing):
Code:
type ConvertibleToString: { def toString: String }
trait Signature { self => ConvertibleToString
var signature: String = ""
def isSigned: Bool = ...
def sign(key: String) = ... // Implementation über self.toString
}
// und jetzt kann ich alles, was eine toString Methode hat, damit signieren.
val s = new List("a", "b", "c") with Signature
s.sign("secret")
Oha. Ein beliebiges Objekt hat nun plötzlich eine Signatur und wäre somit quasi vor Änderung geschützt (wobei man in echt vermutlich eher auf Serializable gehen sollte, anstelle von toString). Ist in Delphi einfach völlig unmöglich. Was da am nächsten hinkäme, wäre dann, eine Art Service zu haben, der Signaturen für Objekte verwaltet. Aber mal ganz ehrlich: Was davon ist der bessere Code?
Duck Typing ist auch extrem nützlich, wenn man mit Interfaces zu tun hat, die man selbst nicht manipulieren kann - also z.B. alles was Teil der Standardlibrary ist. Ich kann einfach Funktionen definieren, die alles als Input schlucken, was eben die Methoden hat, die ich in dieser Methode brauche - ohne dass dafür dieses Objekt ein explizites Interface implementieren müssten. Sprich ich kann damit ganz leicht Kompatibilität herstellen, wo sie das Typsystem ohne tieferen Sinn "zerstört" hat.
Zitat:
Ich frag mich immer was die ganzen Bullshit-Bingo-Spieler des
OOP noch hier im Delphi-Forum suchen
Man kann sich natürlich auch auf dem Wissensstand vor 20 Jahren ausruhen - weil eigentlich sind das ja alles nur völlig wertlose Buzzwords
