Frage

Nach dem dieses Themas , ich sehe, dass viele von denen, die es nicht mögen für den Missbrauch des neuen Schlüsselwort das Potential zitieren. Meine Frage ist, welche Art von Missbrauch? Wie kann das so schlecht missbraucht werden, wie Menschen heftig es nicht mögen zu machen? Ist es nur etwa Purismus? Oder gibt es eine reale Gefahr, dass ich einfach nicht sehen?

War es hilfreich?

Lösung

Einige es als Werkzeug sehen, die missbraucht werden. Wie "Option Strict Off" und "On Error Resume Next" in VB, die "reine" Sprachen wie C # und Java noch nie hatten.

Viele sagten das gleiche über die „var“ Keyword, aber ich sehe es nicht missbraucht werden, sobald es verstanden wurde, dass es nicht das gleiche wie VB „Variante“ war

Es könnte an Orten missbraucht werden, die faul Entwickler wollen nicht Typ auf Klassen prüfen und versuchen, nur dynamische fangen Anrufe anstatt zu schreiben „wenn bla bla ist ...“.

Ich fühle mich persönlich es in Situationen wie richtig verwendet werden, könnte dies letztes Frage, die ich beantworten.

diejenigen stark in die dynamischen .NET-Sprachen

Ich denke, die, die wirklich zu verstehen, es Macht ist.

Andere Tipps

Ich denke, dass eine Menge des Ekels, dass die Menschen auf diese Funktion ausdrücken läuft darauf hinaus, „das ist eine schlechte Sprache-Funktion, weil es schlecht Entwickler erlaubt, schlechten Code zu schreiben.“ Wenn man darüber nachdenkt, von dieser Logik alle Sprache Funktionen sind schlecht.

Wenn ich in einen Block von VB-Code ausführen, der einige Genie mit On Error Resume Next Präfix hat, ist es nicht VB, die ich verfluchen. Vielleicht sollte ich, nehme ich an. Aber in meiner Erfahrung eine Person, die bestimmt wird, einen Cent im Sicherungskasten setzen wird einen Weg finden. Selbst wenn man seine Taschen leeren, wird er seinen eigenen Pennies Mode.

Sie mich, ich freue mich auf einen nützlicheren zwischen C # und Python von interoperabel. Ich bin mehr und mehr Code zu schreiben, der dies tut. Das dynamic Schlüsselwort kann nicht früh genug kommt für diesen speziellen Anwendungsfall, da die aktuelle Art und Weise tut, macht mir das Gefühl, dass ich ein sowjetische akademischen in den 1950er Jahren bin, der für eine Konferenz in den Westen reist: es gibt eine immense Menge an Regeln und Papierkram, bevor ich zu verlassen, ich bin ziemlich sicher, dass jemand wird mir die ganze Zeit zu beobachten ich dort bin, und das meiste, was ich hole, während ich bin es weg von mir an der Grenze getroffen werden, wenn ich zurückkehre .

dynamische ist schlecht, weil Code wie dies überall Pop:

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

statt:

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 Typ Info, keine Kompilierung Prüfung, es ist nicht selbstdokumentiere, keine Typinferenz, damit die Menschen einen dynamischen Verweis auf die Aufrufstelle zu verwenden, gezwungen sein wird, um das Ergebnis zu speichern, um mehr Art Verlust führt und all diese Spiralen nach unten.

Ich fange schon zu fürchten dynamische .

Bearbeiten : Die Gefahr bestanden hat (! Puh) ... und dynamisch wurde, nachdem alle nicht missbraucht, keine Notwendigkeit, nach unten stimmt mich nach 3 Jahren:)

Die wirkliche Gefahr? Gravierender Mangel an Dokumentation. Die Architektur der gesamten Anwendung besteht im Geist der Person (oder Personen), die es geschrieben haben. Zumindest mit starken Typisierung, können Sie gehen sehen, was das Objekt über seine Klassendefinition des Fall ist. Bei der dynamischen Typisierung, müssen Sie die Bedeutung schließen daraus besten Gebrauch ist. Im schlimmsten Fall haben Sie keine Ahnung, was das Objekt ist. Es ist wie alles, was in JavaScript programmiert. ACK!

Wenn die Menschen erkennen, dass sie nicht mit dynamic gut IntelliSense bekommen, werden sie vom Seinem dynamic freudigen Schalter wieder auf dynamic-wenn-notwendig-und-var-at-all-andere-mal.

Die Ziele dynamic sind: Interoperabilität mit dynamischen Sprachen und Plattformen wie COM / C ++ und DLR / Ironpython / IronRuby; sowie C # selbst in IronSmalltalkWithBraces mit allem, was der Umsetzung IDynamicObject drehen.

Gute Zeiten werden von allen werden muß. (Es sei denn, Sie benötigen Code jemand anderes geschrieben zu halten.)

Diese Art wie öffentliche Kameras diskutieren, dass sie können und werden dazu missbraucht werden, aber es gibt Vorteile sie auch zu haben.

Es gibt keinen Grund, warum Sie nicht das „dynamische“ Keyword in Ihrer eigenen Codierung Richtlinie verbieten könnten, wenn Sie sie nicht brauchen. Also, was ist das Problem? Ich meine, wenn Sie verrückte Dinge mit dem „dynamischen“ Stichwort tun wollen und so tun, C # die einige mutierte Cousin von JavaScript ist, mein Gast. Halten Sie einfach diese Experimente aus meiner Code-Basis. ;)

FUD. Es könnte die beste Sache seit geschnittenem Brot sein, aber die ganze Erfahrung, die ich mit VB hatte, JavaScript etc., bringt mir die Schüttelfrost zu wissen, dass C # dynamische Bindung hat. Ich weiß, dass ich in der Lage, rational in naher Zukunft auf sie zu schauen und zu sehen, wie gut das neue Feature Interoperabilität mit dynamischen Sprachen zu ermöglichen, sein wird. Aber es wird einige Zeit dauern. Ich bin ein Mensch, ok? : -)

Ich sehe keinen Grund, warum die gegenwärtige Art und Weise Methoden dynamicly des Aufrufens ist fehlerhaft:

Es dauert drei Linien, es zu tun, oder Sie können eine Erweiterungsmethode auf System.Object fügen Sie es für Sie tun:

class Program
{
    static void Main(string[] args)
    {
        var foo = new Foo();            
        Console.WriteLine(foo.Invoke("Hello","Jonathan"));
    }        
}

static class DynamicDispatchHelper
{
    static public object Invoke(this object ot, string methodName, params object[] args)
    {
        var t = ot.GetType();
        var m = t.GetMethod(methodName);
        return m.Invoke(ot, args);
    }
}

class Foo
{
    public string Hello(string name)
    {
        return ("Hello World, " + name);
    }
}
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top