Che sia un'innvoazione meno importante rispetto alle caratteristiche relative alla security, beh, può darsi.
Ma di certo, almeno dal mio punto di vista, l'usabilità di un browser che supporti i tab è molto, ma molto, ma molto migliore.
Segnalo questo articolo di Patrick Smacchia su TheServerSide.NET.
Molto ben scritto, secondo me.
Illustra in modo chiaro e con diversi esempi di codice i "trucchi" che il compilatore C# (v2.0) adotta per implementare i metodi anonimi, con particolare riguardo per la visibilità delle variabili locali dichiarate esternamente al metodo.
Fonte: questo post di Corrado Cavalli.
E' un po', per così dire, da "geek", però ... guardare per credere.
Mi viene in mente quel programma che va in onda su Mtv (Pimp my Ride), nel corso del quale vengono effettuate le più assurde elaborazioni su automobili scassatissime.
Ora, magari in America non si fanno di questo problemi (anche se ho i miei dubbi a riguardo), però voi la parcheggereste tranquillamente per strada una macchina con un bel 7 pollici LCD in splendida vista sul cruscotto ?
Sino alla versione 1.*, una forte distinzione fra tipi reference e tipi value era costituita dal concetto di nullabilità: un tipo value per definizione non poteva assumere valori null, e analogamente un tipo reference non prevedeva il concetto di non-nullabilità. In pratica, dato ad esempio un riferimento a System.String, qualsiasi accesso ai membri di istanza, che determina una dereferenziazione del riferimento stesso, se non controllata poteva provocare eccezioni a run-time (la famosa NullReferenceException, che poi è la faccina sorridente di una "vecchia" access violation).
La versione 2.0 introduce il concetto di NullableType, mettendo di fatto a disposizione quello che, in molti casi, un programmatore si era costruito a mano: è ora possibile dichiarare un tipo di valore "nullabile", assegnarvi null e verificare che un'istanza sia o meno nulla. C'è molta documentazione a riguardo, e probabilmente molti hanno già avuto modo si sperimentare questa nuova caratteristica in una delle versioni preliminari che MS ha rilasciato fino ad ora (siamo alla beta 2, inutile rimarcarlo ancora).
Facciamo due conti: tipi valore non nullabili (da sempre), tipi valore nullabili (v2.0), tipi reference nullabili (da sempre) ... e se uno volesse utilizzare un tipo reference non nullabile ? E' possibile garantire questo vincolo, e come ?
Alcune settimane fa, Cyrus ha pubblicato una serie di post (qui il primo) che illustrano come la necessità di avere a disposizione tipi reference non nullabili sia effettivamente percepita, ma non così semplice da realizzare dal punto di vista del framework.
Una proposta di implementazione viene da Spec#.
E' un progetto di ricerca interno a Microsoft, volto ad estendere le funzionalità del linguaggio C#. Tra le caratteristiche introdotte, oltre ai Non-Nullable types, c'è il supporto alle checked exceptions (stile Java, e oltre). Vi rimando a questo documento introduttivo per una panormaica più completa.
C# è nato ex-novo e si basa sulla esperienza di anni di sviluppo e perfezionamento dei linguaggi di programmazione OO. Non per niente molte persone, non solo i suoi detrattori, si divertono a trovare le similitudini con altri linguaggi (Java e C++ principalmente), e nascono i dibattiti sui motivi per i quali una caratteristica sia stata inclusa o esclusa dall'implementazione.
Sulle checked exceptions mi ricordo di aver letto alcune discussioni (putroppo non ricordo i link però :-)), la nullabilità dei tipi è un argomento che attira sempre vivaci botta e risposta.
E' interessante notare come Microsoft porti avanti lo sviluppo e l'inclusione delle caratteristiche non originariamente previste: molto è affidato ai progetti di ricerca.
I Generics sono stati studiati ed implementati dal progetto Gyro come estensione di Rotor, e probabilmente molte delle caratteristiche sviluppate sono poi entrate nel ramo ufficiale.
Spec# introduce i concetti di tipi non nullabili ed eccezioni checked, due dei punti maggiormete richiesti dagli sviluppatori.
Prendiamo Cw (C-Omega). Le innovazioni, in questo caso, sono forse di portata ancora maggiore.
Il supporto all'esecuzione asincrona fornisce una sintassi a mio giudizio elegantissima a molti problemi di programmazione concorrente, eliminando anche diverse fonti di errori.
L'avvicinamento di CTS, XML e dati relazionali, è, almeno nelle intenzioni, a dir poco rivoluzionario, e non è un caso che Anders Hejlsberg veda in questo settore (gestione dei dati) la direzione principale nello sviluppo della versione 3 del suo linguaggio (C#, appunto).
Insomma, credo che dai progetti di ricerca si possano evincere, per lo meno, molte delle tendenze future.
E credo sia una cosa estremamente positiva il fatto che Microsoft dia la possibilità di sperimentare, fin da ora, queste novità. Che sono, sì, in fase super-preliminare, ma probabilmente contengono il seme di qualcosa di molto più grosso.