Parola chiave dinamica C # 4: perché no?

Question

Dopo aver letto molte delle risposte a questa discussione , vedo che molti di coloro che non lo apprezzano citano il potenziale abuso della nuova parola chiave. La mia domanda è: che tipo di abuso? Come si può abusare così tanto da far sì che alle persone non piaccia con veemenza? Si tratta solo di purismo? O c'è una vera trappola che non vedo?

Answer 1

Alcuni lo vedono come uno strumento che verrà abusato. Come " Opzione rigoroso Off " e " On Error Riprendi Successivo " in VB che "puro" lingue come C # e Java non hanno mai avuto.

Molti hanno detto la stessa cosa di " var " parola chiave, ma non vedo che viene abusato, una volta capito che non era lo stesso di VB " Variant "

Potrebbe essere abusato in luoghi in cui gli sviluppatori pigri non vogliono controllare i tipi sulle classi e provare a catturare chiamate dinamiche invece di scrivere "se blah è Blah ..."

Personalmente ritengo che potrebbe essere usato correttamente in situazioni come this recente domanda a cui ho risposto.

Penso che quelli che comprendono davvero il suo potere siano quelli fortemente nei linguaggi .NET dinamici.

Answer 2

Penso che gran parte della repulsione che le persone stanno esprimendo a questa funzione si riduce a "questa è una caratteristica del linguaggio cattivo perché permetterà agli sviluppatori cattivi di scrivere codice cattivo." Se ci pensate, secondo quella logica tutte le funzionalità del linguaggio sono cattive.

Quando incontro un blocco di codice VB che un genio ha come prefisso On Error Resume Next , non è VB che maledico. Forse dovrei, suppongo. Ma nella mia esperienza una persona che è determinata a mettere un penny nella scatola dei fusibili troverà un modo. Anche se svuoti le tasche, si modellerà i suoi penny.

Io, non vedo l'ora di un modo più utile di interagire tra C # e Python. Sto scrivendo sempre più codice per farlo. La parola chiave dynamic non può arrivare abbastanza presto per quel particolare caso d'uso, perché l'attuale modo di farlo mi fa sentire come un accademico sovietico negli anni '50 che sta viaggiando in Occidente per una conferenza : c'è un'enorme quantità di regole e scartoffie prima che me ne vada, sono abbastanza sicuro che qualcuno mi starà guardando tutto il tempo che ci sarò, e la maggior parte di ciò che raccolgo mentre sono lì sarà portato via da io al confine quando torno.

Answer 3

dinamico è errato perché codice come questo comparirà ovunque:

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

anziché:

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

Il primo, non ha informazioni di tipo statico, nessun controllo del tempo di compilazione, non è auto-documentazione, nessuna inferenza di tipo, quindi le persone saranno costrette a usare un riferimento dinamico sul sito della chiamata per memorizzare il risultato, portando a una maggiore perdita di tipo e tutte queste spirali verso il basso.

Sto già iniziando a temere dinamica .

Modifica : il pericolo è passato (Accidenti!) ... e dopo tutto la dinamica non è stata abusata, non è necessario votarmi dopo 3 anni :)

Answer 4

La vera trappola? Grave mancanza di documentazione. L'intera architettura dell'applicazione esiste nella mente della persona (o delle persone) che l'ha scritta. Almeno con la tipizzazione forte, puoi vedere cosa fa l'oggetto tramite la sua definizione di classe. Con la digitazione dinamica, nella migliore delle ipotesi è necessario dedurne il significato dal suo utilizzo. Nel peggiore dei casi, NON hai IDEA quale sia l'oggetto. È come programmare tutto in JavaScript. ACK!

Answer 5

Quando le persone si rendono conto che non ottengono buoni IntelliSense con dinamico , torneranno da dinamico -happy a dinamico -quando-necessario-e var -at-all-altre volte.

Gli scopi di dinamico includono: interoperabilità con linguaggi e piattaforme dinamici come COM / C ++ e DLR / IronPython / IronRuby; oltre a trasformare C # stesso in IronSmalltalkWithBraces con tutto ciò che implementa IDynamicObject .

I bei tempi saranno vissuti da tutti. (A meno che non sia necessario mantenere il codice scritto da qualcun altro.)

Answer 6

È un po 'come discutere delle telecamere pubbliche, sicuramente possono e saranno usate in modo improprio, ma ci sono anche dei vantaggi nel possederle.

Non vi è alcun motivo per cui non si possa mettere fuori legge la "quotazione dinamica" parola chiave nella tua guida alla codifica se non ne hai bisogno. Allora, qual'è il problema? Voglio dire, se vuoi fare cose folli con la " dinamica " parola chiave e fingere C # è un cugino mutante di JavaScript, sii mio ospite. Tieni questi esperimenti fuori dalla mia base di codice. ;)

Answer 7

FUD. Potrebbe essere la cosa migliore dopo il pane a fette, ma tutta l'esperienza che ho avuto con VB, JavaScript, ecc., Mi fa venire i brividi di sapere che C # avrà un'associazione dinamica. So che sarò in grado di esaminarlo razionalmente nel prossimo futuro e vedere quanto sarà bella quella nuova funzionalità per consentire l'interoperabilità con i linguaggi dinamici. Ma ci vorrà del tempo. Sono umano, ok? : -)

Answer 8

Non vedo un motivo per cui l'attuale modo di invocare metodi in modo dinamico sia imperfetto:

Sono necessarie tre righe per farlo, oppure puoi aggiungere un metodo di estensione su System.Object per farlo per te:

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);
    }
}