Conosciamo tutti le aggiunte al recente
C# 3.0 presenti nel Framework 3.5. Però non tutti si trovano nella situazione di potere allegramente aggiornare i propri progetti al nuovo framework (dannato Windows 2000).
Ma non tutto è perso, vale comunque la pena di passare a
Visual Studio 2008 dato che questi compila
anche per .Net 2.0 e che, come mi ha fatto notare un mio collega, molte delle nuove caratteristiche di C# 3.0 non sono altro che zucchero sintattico gestito dal compilatore e non richiedono un runtime diverso da quello usato dal .net framework 2.0.
Quindi la seguente linea è perfettamente valida in .Net 2.0 (con VS 2008):
var o = new List<string> { "One", "Two", "Three" };
Notate la
tipizzazione implicita delle variabili locali e l'
inizializzazione della collection.
Altro zucchero sintattico è la
definizione semplificata delle proprietà:
class Person
{
public string Nome { get; set; }
public string Cognome { get; set; }
}
Un oggetto Person si può quindi
creare ed inizializzare con questa sintassi ultra comoda:
var p = new Person { Nome = "Mario", Cognome = "Rossi" };
Viene naturale a questo punto utilizzare una delle caratteristiche più simpatiche di C# 3.0: gli
extension methods.
Per chi non lo sapesse, gli
extension methods permettono di estendere classi esistenti aggiungendo metodi non definiti all'interno delle stesse. In breve, è zucchero sintattico per nascondere l'utilizzo di un metodo statico definito altrove. Si distinguono da metodi statici "normali" mediante l'utilizzo della keyword
this nel primo parametro, che dev'essere del tipo a cui si vuole "aggiungere" il metodo.
Per esempio potremmo voler implementare ciò che manca nella vita di ogni smanettone, ovvero un
ToString() che non generi eccezioni se l'oggetto su cui si invoca è nullo:
public static class TextHelpers
{
public static string ToStringSafe(this object ob)
{
if (null != ob) return ob.ToString();
else return string.Empty;
}
}
In breve, la chiamata a
o.ToStringSafe();
è tradotta dal compilatore in:
TextHelpers.ToStringSafe(o);
Trattandosi quindi di un metodo statico, possiamo gestire anche lo sventurato casso di riferimenti nulli.
Ma quando ho provato a compilare il precedente esempio, il compilatore si è burocraticamente rifiutato di fare il suo lavoro lamentandosi della mancanza di un attributo presente nel framework 3.5 (e quindi assente nel 2.0):
error CS1110: Cannot define a new extension method because the compiler required type 'System.Runtime.CompilerServices.ExtensionAttribute' cannot be found. Are you missing a reference to System.Core.dll?Il problema è questo: il compilatore è in gradi di gestire gli extension methods, non è in grado di decorarne la definizione con l'attributo
ExtensionAttribute che è ciò che in fondo lo distingue da un metodo statico qualunque. Possibile che un cavillo legale così stupido ci impedisca di usufruire di una
feature così
trendy? E se provassimo ad "ingannare" il compilatore? In che modo? Beh, vuole un ExtensionAttribute? Eccolo:
namespace System.Runtime.CompilerServices
{
public class ExtensionAttribute : Attribute { }
}
Basta aggiungere il precedente codice al nostro progetto per accontentare il compilatore e noi possiamo scrivere finalmente:
Console.WriteLine(o.ToStringSafe());
Bello, eh?
Prendiamo ad esempio un altro e
xtension method (simile alle pletore di quelli disponibili nel framework 3.5) che applica una procedura ad ogni elemento di una collection:
public delegate void Func<T>(T t);
public static class CollectionsHelpers
{
public static void Apply<T>(this ICollection<T> col,
Func<T> func)
{
foreach (T item in col)
{
func(item);
}
}
}
Ecco come possiamo utilizzarlo nel framework 2.0 utilizzando Visual Studio 2008:
o.Apply((string x) => { Console.WriteLine(x); });
Ebbene sì, ovunque potremmo usare delegate o metodi anonimi, ora possiamo usare le
lambda expression.
Anche col framework 2.0!
