C#4 dynamisches Schlüsselwort - warum nicht?

Question

Nachdem ich viele der Antworten auf dieses Thema Ich sehe, dass viele derjenigen, die sich dagegen aussprechen, das Missbrauchspotenzial des neuen Schlüsselworts anführen. Meine Frage ist, welche Art von Missbrauch? Wie könnte es so sehr missbraucht werden, dass die Leute es vehement ablehnen? Geht es nur um Purismus? Oder gibt es einen echten Fallstrick, den ich einfach nicht sehe?

Answer 1

Ich denke, dass ein Großteil der Abneigung, die die Leute gegenüber dieser Funktion zum Ausdruck bringen, darauf hinausläuft, dass "dies eine schlechte Sprachfunktion ist, weil sie es schlechten Entwicklern ermöglicht, schlechten Code zu schreiben". Wenn man darüber nachdenkt, würde diese Logik todo Sprachmerkmale sind schlecht.

Wenn ich auf einen VB-Code-Block stoße, dem irgendein Genie den Zusatz On Error Resume Next Es ist nicht VB, das ich verfluche. Vielleicht sollte ich das tun, nehme ich an. Aber meiner Erfahrung nach wird eine Person, die entschlossen ist, einen Pfennig in den Sicherungskasten zu stecken, einen Weg finden. Selbst wenn man ihm die Taschen leert, wird er sich seine eigenen Pennys basteln.

Ich freue mich auf eine nützlichere Art der Interoperabilität zwischen C# und Python. Ich schreibe mehr und mehr Code, der dies tut. Die dynamic Für diesen speziellen Anwendungsfall kann das Schlüsselwort gar nicht früh genug kommen, denn bei der derzeitigen Vorgehensweise fühle ich mich wie ein sowjetischer Akademiker in den 1950er Jahren, der zu einer Konferenz in den Westen reist: Es gibt eine Unmenge an Vorschriften und Papierkram, bevor ich ausreisen darf, ich bin mir ziemlich sicher, dass mich jemand die ganze Zeit über beobachten wird, und das meiste, was ich dort mitnehme, wird mir bei meiner Rückkehr an der Grenze wieder abgenommen.

Answer 2

Einige sehen darin ein Instrument, das missbraucht werden wird. Wie "Option Strict Off" und "On Error Resume Next" in VB, die "reine" Sprachen wie C# und Java noch nie hatten.

Viele sagten dasselbe über das "var"-Schlüsselwort, doch ich sehe nicht, dass es missbraucht wurde, sobald verstanden wurde, dass es nicht dasselbe wie VBs "Variant" war.

Es könnte an Stellen missbraucht werden, an denen faule Entwickler keine Typüberprüfung von Klassen wünschen und einfach versuchen, dynamische Aufrufe abzufangen, anstatt "if blah is Blah ..." zu schreiben.

Ich persönlich bin der Meinung, dass es in folgenden Situationen richtig eingesetzt werden könnte este Frage, die ich kürzlich beantwortet habe.

Ich denke, dass diejenigen, die wirklich verstehen, wie mächtig es ist, diejenigen sind, die sich intensiv mit den dynamischen .NET-Sprachen beschäftigen.

Answer 3

dynamisch ist schlecht, weil Code wie dieser überall auftaucht:

public dynamic Foo(dynamic other) {
  dynamic clone = other.Clone();
  clone.AssignData(this.Data);
  return clone ;
}

anstelle von:

public T Foo<T>(T other) where T: ICloneable, IAssignData{
    T clone = (T)other.Clone();
    clone.AssignData(this.Data);
    return clone;
}

Die erste hat keine statischen Typinformationen, keine Kompilierzeitüberprüfung, sie ist nicht selbstdokumentierend, keine Typinferenz, so dass die Leute gezwungen sind, eine dynamische Referenz an der Aufrufstelle zu verwenden, um das Ergebnis zu speichern, was zu weiteren Typverlusten führt, und all dies führt zu einer Spirale nach unten.

Ich fange schon an zu fürchten dynamisch .

Answer 4

Der eigentliche Fallstrick? Ein gravierender Mangel an Dokumentation. Die gesamte Architektur der Anwendung existiert nur im Kopf der Person (oder Personen), die sie geschrieben hat. Zumindest bei der starken Typisierung können Sie anhand der Klassendefinition sehen, was das Objekt tut. Bei der dynamischen Typisierung müssen Sie die Bedeutung bestenfalls aus der Verwendung des Objekts ableiten. Schlimmstenfalls haben Sie KEINE AHNUNG, was das Objekt ist. Das ist so, als würde man alles in JavaScript programmieren. ACK!

Answer 5

Das ist in etwa so, wie wenn man über öffentliche Kameras diskutiert: Sicherlich können und werden sie missbraucht werden, aber es gibt auch Vorteile, sie zu haben.

Es gibt keinen Grund, warum Sie das Schlüsselwort "dynamic" nicht in Ihrer eigenen Kodierungsrichtlinie verbieten könnten, wenn Sie es nicht brauchen. Wo liegt also das Problem? Ich meine, wenn Sie verrückte Dinge mit dem Schlüsselwort "dynamic" anstellen und so tun wollen, als sei C# ein mutierter Cousin von JavaScript, bitte sehr. Aber halten Sie diese Experimente von meiner Codebasis fern ;)