INullableValue removed from .NET 2.0 RTM??

INullableValue removed from .NET 2.0 RTM??

• Maheswaran

  I had another look. Basically Nullable types are treated the same as reference types now. Just as with a reference type, if you have a variable set to null, you cannot tell what type it is. (There's no object on the managed heap backing it.) Try the following code:

  int  i = null;
  object oi = i;
  Console.WriteLine(oi is int ); // false
  string s = null;
  object os = s;
  Console.WriteLine(os is string);// false

  Note that if i is assigned a value such as 42, then (i is int) and (i is int ) both evaluate to true.

  So I don't think there is a way around this, but I might be wrong.

  
  
  

• boulder

  You'll want to read Somasegar's blog post regarding the DCR on Nullables:

   

  http://blogs.msdn.com/somasegar/archive/2005/08/11/450640.aspx

   

  Basically, nullables are now truly null. They are an intrinsic type in the CLR now rather than simply being implemented using generics. Now nullables are truly null. For instance:

   

  int i = null;

  if(i==null) {

    Console.WriteLine("I'm null!");

  }

   

  So your code above can be simplified into a check for null rather than checking if the type is nullable and doesn't have a value or is a null object reference.

   

  if(value == null) {

    // Now satisfies both your if and else if blocks

  }

   

  Hope that helps.

  
  
  

• BoneCrusher

  You're not the only one who has run into this problem. I stumbled across this post, which discusses the exact same problem:

   

  http://irritatedvowel.com/CS/blogs/pete_browns_blog/archive/2005/09/08/74.aspx

   

  I tried a few ideas yesterday, but couldn't think of anything obvious to differentiate between a reference type and a nullable type. Anyone else have ideas

  
  
  

• Big V

  That's very interesting, but this hurts quite a bit. I wish they had left the Nullable<T> class implementing the INullableValue interface and made the CLR change.

  The code block in my post is part of a data abstraction layer and it needs to be able to differentiate between nullable value types and nullable objects since the system handles the semantics of objects and values differently.

  As it stands, I have no idea how to cleanly implement the intended logic with the new language features. I was thinking of trying to check whether the value was null and then to also check the value's type to see whether the IsValueType property is true, but since the null check is going to always return null, I'm not sure how to do that.

  public void SomeMethod (object value)
  {
     if (value == null && IsNullableValueType(value))
     {
        //special case for nullable value types
     } else {
        //normal case
     }
  }
  
  private bool IsNullableValueType( object value )
  {
     //what should go here
  }

  
  
  

• RobertRFreeman

  I came up with a solution that suits my present purpose, but it will not due for generic purposes. I am walking the readable/writable properties of a class (the data abstraction layer uses reflection) and pulling PropertyInfo information for each property that is found, so I have that type information to work with.

  So, I made a nullable value type checking method that requires both a value and its type information to do the trick:

  public static bool IsNullableValueType(object value, Type type)
  {
     if (!type.IsValueType)
     {
        return false;
     }
  
     if (value == null)
     {
        return true;
     }
  
     if (type.GetProperty("HasValue") != null)
     {
        return true;
     }
  
     return false;
  }

  This is awful that we have to do this kind of thing... we need INullableValue back! The solution I'm using will not work in most cases since you'll need to already known the object's undelying type before calling the method -- value.GetType() will not work since null Nullable<T> cases will evaluate to calling GetType() on a null reference.

  The problem that the C# team was attempting to solve by moving Nullable<T> dereferencing into the CLR simply did not exist on a broad scale. The fact that we had to write special logic to handle INullableValue was a good thing -- it was a special case after all.

  
  
  
• INullableValue removed from .NET 2.0 RTM??