(luKa)

Quando dici:

Per permettere l'evoluzione (bug fix e sicurezza) è stato conveniente

- rompere la compatibilità all'indietro con le precedenti versioni dei NullableTypes 1.0 e 1.2.
- interromplere il supporto alla versione 1.0 del .NET Framework

puoi spiegare il perchè? sono curioso...

1) rompere la compatibilità all'indietro con le precedenti versioni dei NullableTypes 1.0 e 1.2.
Le modifiche introdotte dalla 1.2 non ropono la compatibilità, per esempio grazie alle publisher policy è possibile far girare i test della 1.0 sull'assembly della 1.2 e vedere che tutti passano ancora.

Purtroppo Damien mi ha segnalato un bug che andava risolto: Il metodo Add del NDateTime modificava il valore del NDateTime invece che restituire un nuovo NDateTime (tutti i built-in type si comportano in questo modo che in effetti ha dei vantaggi).
Ho dovuto cambiare la signature del metodo, non solo l'implementazione e questo ha rotti la compatibilità.

-----

2) interromplere il supporto alla versione 1.0 del .NET Framework

NullableTypes 1.2 sono compilati col framework 1.1 ma grazie all'alto livello di forward comparibility del framework 1.0, possono essere eseguiti perfettamente col framework 1.0 (e anche con questo tutti i test danno barra verde) .

Nella versione 1.3 beta ho migliorato la sicurezza del codice riducendo i permessi che sono attivi mentre il codice dei nullable types è in esecuzione (in questo modo anche se il codice chiamante ha tutti i privilegi il codice dei nullabletypes non li può utilizzare ed un eventuale bug che potrebbe essere sfruttato in modo malizioso darebbe meno possibilità di far danni).
Questo ha richiesto di applicare un SecurityAction.RequestRefuse a un permission attribute presente nella 1.1 e non nella 1.0.
Quindi i NullableTypes 1.3 non possono essere eseguiti (e nemmeno l'assembly caricato) col framework 1.0.

-----

Qualora ricevessi numerose richieste di mantenere la compatibilità con la 1.2 e il supporto del framework 1.0 sarei costretto a riconsiderare le modifiche che ho descritto.

grazie!

Un'altra domanda... che senso hanno il NullableTypes in .NET 2.0?

Cosa danno in più?

I motivi per cui vorrei portare i NTypes in .NET 2.0 sono 2.

Il primo e più importante per supportare chi ha realizzato progetti con .NET 1.x e i NTypes 1.x e vuole portarli in .NET 2.0.

Il secondo è che i nullable types di C# 2.0 hanno lo scopo di rendere nullable qualsiasi value-type, non solo i built-in type mentre i NullableTypes sono ottimizzati per i built-in type.
Per ottenere questa utile generalità i nullable types di C# 2.0 richiedono al programmatore con molto frequenza di:
- testare HasValue
- quindi accedere a Value per usare il metodi dal Value-Type originale

Questo è molto poco OO equivalentemente va contro il comodo pattern 'Null Object'.

Invece i NTypes permettono di accedere ai metodo/property di uso + frequente direttamente con il vincolo che sono usabili solo coi i built-in types.

Ecco un esempio:
// NullableTypes
NDecimal nd1 = GetANullableTypesDecimal();
NDecimal nd2 = NDecimal.Floor(nd1);

// C#2.0 nullable types
Decimal? nd3 = GetAC#20NullableTypesDecimal();
Decimal? nd4;
if (nd3.HasValue)
nd4 = Decimal.Floor(nd3.Value);
else
nd4 = null;

E ce ne sono molti altri (NGuid.ToByteArray, NDecimal.Truncate, etc.)

Un ultimo motivo va a quei linguaggi managed che non implementano le estensioni del compilatore che rendono pratico l'uso dei nullable types nonostante le limitazioni attuali dei Generics di .NET 2.0 che si riflettono sul tipo System.Nullable<T>.

I motivi per cui sono utili nel .NET 1.x anche per il .NET 2.0 me gli ha spiegati M.rkino qui sul suo blog: http://blogs.ugidotnet.org/Markino/archive/2005/11/04/29178.aspx