The main reason that I don't want to is the ugliness of it. I've worked hard to completely separate my business tier and data tier, and to introduce a data type that begins with Sql into my business tier just seems wrong to me. What if I want to map my objects to an XML data store some day in the near future? Then I must refactor both my business and my data tier at that point so that all of my SqlDateTime fields are some other type.
And anyhow, the data mapping point was just an example -- I've found many cases in which I find myself checking for a "special value" that indicates null (such as minimum or maximum values for DateTimes, ints, etc.). There's just no way to cleanly express null with value types even if I decide that I can deal with the overhead of heap management versus stack, and I guess my point is that this is a common thing that I find myself wishing I could do. Thanks, joe -----Original Message----- From: Eric Gunnerson [mailto:[EMAIL PROTECTED]] Sent: Monday, June 10, 2002 3:51 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Value type references (versus object references) If you want a primitive type that also expresses the concept of null, why not use the SqlDateTime type? -----Original Message----- From: Joe Duffy [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 12: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. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
