Hi,

we had the same problem with value types. We are creating an application
development framework, and wanted to provide the possibility of optional
arguments. There we also found, that not being able pass a non-valid
value (like null) to a value type argument is quite an obstacle. In the
end we provided two solutions, one is using default values if the
argument is not provided (like in C++), the other one is using the
object type for value type arguments, providing the real type as an
attribute to have run-time type checking.
It would be really nice, if there would be some general support for a
"validity" flag on value types to handle this kind of problems. 

Regards
  Csaba

> -----Original Message-----
> From: Joe Duffy [mailto:[EMAIL PROTECTED]]
> Posted At: Tuesday, June 11, 2002 1:06 AM
> Posted To: dotnet
> Conversation: Re: Value type references (versus object refere nces)
> Subject: Re: Value type references (versus object refere nces)
> 
> 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

You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced 
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.

Reply via email to