Un futuro per Dynamic Feature Runtime nel contesto di C#?

Question

Così C# si è evoluto come linguaggio tipicamente statico e fa un lavoro più che perfetto nel mantenere la nicchia nello sviluppo della linea di applicazioni aziendali con framework .net.

Ora, chiaramente, negli ultimi tempi, microsoft ha iniziato a fare passi da gigante verso altri paradigmi fondamentali per i quali C# e .net non hanno mai preteso di essere lo strumento fino al recente passato.

Uno di questi è il DLR

Ok Divercity lingua - grande, penso, solo ora sembra che devo cambiare il modo in cui sto pensando, quando scrivo i miei entità di business con le classi, se voglio approfittare della funzionalità ... Che è bello, e sto imparando tutto il nuovo. Ma prima di farlo ho alcune domande per la rispettata comunità in merito. Ora, per motivi di chiarezza, sono più interessato all'applicazione del DLR insieme a CLR.

Iniziamo dunque:

1. Per il vostro parere, è DLR una funzione valida che desrves di essere guardato dal punto di vista aziendale di sviluppo del software commerciale? Cioè, C# ha davvero bisogno che una caratteristica continui a fare ciò che sta facendo o avrebbe più senso passare a un linguaggio standardizzato tipicamente in quel momento?

2. dove la combinazione di sviluppo e la scrittura di codice con CLR e DLR brillare in termini di applicabilità azienda? Esempi concreti sarebbero i più apprezzati per me.

3. vantaggi.

Ora MSDN dice questo:

Provides Future Benefits of the DLR and .NET Framework Languages implemented by using the DLR can benefit from future DLR and .NET Framework improvements. For example, if the .NET Framework releases a new version that has an improved garbage collector or faster assembly loading time, languages implemented by using the DLR immediately get the same benefit. If the DLR adds optimizations such as better compilation, the performance also improves for all languages implemented by using the DLR.

Bene grande, ma come esattamente? E non otterrò lo stesso se aggiornerò comunque il mio framework? Perché devo scrivere in DLR per quello?

1. potete inserire esempi di codice per mostrare che DLR può fare una migliore jon di regolare C#?

2. Vale la pena di imparare a essere un ingegnere di rete .net, o è più o meno una caratteristica isoterica per dire semplicemente: "Oh, siamo migliori di Ruby, bc possiamo farlo anche più"?

3. Quali sono l'overhead di combinare quei 2 o semplicemente utilizzando il DLR automaticamente in app. sviluppando?

4. Può DLR essere utilizzato con F #?

Cordiali saluti.

Answer 1

Potrebbe essere utile chiarire che il DLR è un'API stratificata in cima al CLR per abbassare la barra per l'implementazione delle funzioni di linguaggio di digitazione dinamico. Puoi usarlo end-to-end come fanno IronPython, IronRuby, Clojure e altri linguaggi per implementare la tua lingua. Puoi usarlo pezzo-pasto come C# o VB per ottenere semplicemente il caching dinamico del sito di chiamata (ricerca di cache polimorfica in linea per informazioni generali sui concetti). Quindi, C# aggiunge la parola chiave 'dinamica' e utilizza i CallSite, i raccoglitori, DynamicMetaObjects, ecc. Del DLR per implementare questa funzione linguistica.

Sì, il DLR è una funzionalità valida e ha senso per C#. C# era dietro VB per l'interoperabilità COM, le origini dati non tipizzate (DB, XML, ecc.) E per la sintassi più leggera dietro le pagine web (ad esempio, button.text = "yo"). Quando amo una lingua, la trovo generalmente utile, o ho messo a punto la mia prodezza, mi piace usare quella lingua il più possibile. Non voglio dover lavorare insieme e creare un sovraccarico di manutenzione nella mia soluzione utilizzando più lingue, a meno che non sia proprio necessario. La "dinamica" di C# mi consente di fare cose che potrei già fare in C# in un modo molto più semplice e più gustoso, e certamente significa che non devo ricorrere a un linguaggio puramente dinamico o opzionalmente esplicitamente digitato per scrivere codice in più modi situazioni ora.

Lo sviluppo del codice con DLR si attiva se si sta tentando di aggiungere funzionalità di tipo dinamico a una lingua o un sistema grande e ricco. Come spesso citato, "qualsiasi programma sufficientemente complicato contiene una ... implementazione di ... Lisp." Se stai riscontrando che hai bisogno di un accesso dinamico a dati o oggetti, con un calcolo di ciò che un'operazione significa dati alcuni input e vuoi mettere in cache quell'azione per successivi calcoli simili in quella posizione nel programma, il DLR ti aiuta a farlo in un modo più economico Il fatto è che potresti non aver nemmeno bisogno di usare il DLR a questo livello poiché C# ha introdotto "dinamico" per te. Tuttavia, è possibile implementare IDynamicMetaObjectProvider su alcuni oggetti che rappresentano le origini dati in modo che possano partecipare alle operazioni di associazione eseguite dalle chiamate di chiamate dinamiche di C#. Un esempio di questo sarebbe se XmlElement implementasse IDMOP in modo da poter scrivere qualcosa come: dynamic x = source.GetXmlElement (...); ... x.Clienti [i] .Address.City == "Erie" ...

I vantaggi sono un grado più elevato di espressività nel codice scritto rispetto ai dati o agli oggetti che sono intrinsecamente dinamici per loro natura, piuttosto che avere per esprimere complicate dichiarazioni di tipo intermedio e fare un sacco di chiamate o.GetBlahByName ("qualunque").

Il paragrafo che hai citato dai documenti DLR riguarda le implementazioni linguistiche create sul DLR. Sì, certo che anche le tue app hanno i vantaggi. Il punto era più su come, ad esempio, IronPython abbia avuto modo più veloce non solo a causa dell'avvento del DLR ma perché lo stesso CLR ha funzionato che indirettamente ha migliorato l'implementazione di IronPython sul DLR.

Non disturbare l'apprendimento del DLR a meno che non sia necessario aggiungere un accesso dinamico memorizzato nella cache alla propria lingua o sistema. La maggior parte delle persone non codifica a questo livello di complessità. La maggior parte delle persone usa le lingue e le strutture, poche persone le implementano.

F # potrebbe utilizzare il DLR, ma un malinteso comune è che F # è un linguaggio dinamico. Non è. È tipicamente scritto in modo statico, ma non è tipizzato esplicitamente in tutti i casi, il che è ciò che confonde le persone. Sembra leggero sintatticamente a causa dell'uso massiccio del tipo di inferenza e degli spazi bianchi significativi. Se F # un giorno decidesse di aggiungere un modello di tipo "dinamico" come C#, avrebbe quindi senso utilizzare il DLR per la facilità di implementazione e per l'interoperabilità con C#, i linguaggi dinamici su .NET, le librerie dinamiche e i framework , ecc

Bill