I'm sure that Ian Griffiths will come back to you on value-type initialization, but I've a quick question: why aren't you just using the Sql types in your object?
I'd point out that sql semantics don't map (as you've noticed) directly to programming language semantics -- in particular, (DB) null != (programming) null. Search the archives on DOTNET for a long discussion of this. John > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED]] On Behalf Of Joe Duffy > Sent: Friday, June 07, 2002 9:48 PM > To: [EMAIL PROTECTED] > Subject: [ADVANCED-DOTNET] Value type references (versus > object references) > > > Perhaps I am asking this question out of ignorance, but why > are value type references handled differently than object > references? I understand that value type instantiations are > held on the stack versus the heap, but I must be missing > something about the way in which references to these objects > are held (does each reference actually store a copy of the > value since they are passed by value? if so, how does example > #2 below work?). I suppose, if I were not lazy, that I could > examine the bytecode generated, but I figured that somebody > on this list could provide a good explanation. > > For instance, I am mostly annoyed by the handling of > references to NULL, which apparently value type references > are incapable of. Let me illustrate an example. > > Say I am instantiating an entity object that represents some > logical coupling of information stored in a relational > database (common task, right?). Now, assume that I have a > date column in one of the tables in the database that I am > interested in representing within my object, which happens to > hold a NULL value for the entity that I am loading (again, > fairly common). > > It seems that my options for representing a NULL DateTime are > as follows: > > 1) > DataReader reader = // ... > DateTime myDateColumn = // ... > // ... > if (reader["my_date_column"] is DBNull) { > myDateColumn = DateTime.MinValue; // or some other "special > value" indicating NULL } else { > myDateColumn = (DateTime)reader["my_date_column"]; > } > > One of the problems with this approach, is that wherever > myDateColumn is referenced, the code needs to know that > DateTime.MinValue signifies a NULL or empty value. Isn't this > what NULL is for?!? > > 2) > DataReader reader = // ... > object myDateColumn = // ... > // ... > if (reader["my_date_column"] is DBNull) { > myDateColumn = null; > } else { > myDateColumn = reader["my_date_column"]; > } > > Obviously a better - and more true - representation of the > value of this field; however, then I lose type safety, am > forced to recast myDateColumn to DateTime whenever I access > it, etc., etc. This gets messy after a while. > > Why is it that I cannot simply do: > 3) > DataReader reader = // ... > DateTime myDateColumn = // ... > // ... > if (reader["my_date_column"] is DBNull) { > myDateColumn = null; > } else { > myDateColumn = (DateTime)reader["my_date_column"]; > } > > In addition, I find it odd that, should I go with #1 above, > the following does not work: object xxx = > (myDateColumn.Equals(DateTime.MinValue) ? null : myDateColumn); > > ...while the following does: > object xxx = (myDateColumn.Equals(DateTime.MinValue) ? null : > (object)myDateColumn); > > Thanks in advance. > > Best Regards, > joe duffy > > You can read messages from the Advanced DOTNET archive, > unsubscribe from Advanced DOTNET, or subscribe to other > DevelopMentor lists at http://discuss.develop.com. > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
