On Thu, 27 Oct 2011 14:06:47 -0400, Steve Teale <[email protected]>
wrote:
On Thu, 27 Oct 2011 13:58:54 -0400, Steven Schveighoffer wrote:
On Thu, 27 Oct 2011 13:53:02 -0400, Steve Teale
<[email protected]> wrote:
On Thu, 27 Oct 2011 13:09:43 -0400, Steven Schveighoffer wrote:
On Thu, 27 Oct 2011 12:58:57 -0400, Steve Teale
<[email protected]> wrote:
On Thu, 27 Oct 2011 16:16:26 +0200, Alex Rønne Petersen wrote:
On 27-10-2011 15:50, Steve Teale wrote:
[snip]
Well, yes, that was my first reaction, but I thought I'd ask - if there
was a spare bit somewhere in Variant, would it do much harm, and Variant
is getting a makeover. Maybe there are circumstances other than database
interactions where it could be useful.
Steve
Speaking as the one making over variant, let me see if I understand your use
case. Similar to typecons.Nullable, you want to be able to test any type for
isNull and be to 'nullify' any type. Correct?
Does nullifying a value wipe it clean? i.e. can you ever un-nullify something?
If you assign to a nulled variant, should there be some sort of special
behavior?
Should 'hasValue' return false or true? If true, what should 'get' & company
return?
'type' should return the TypeInfo of the type that was nullified, correct?
What should 'toString' return?
One thing that concerns me is the API. The new Variant supports reflection via
opDispatch, so adding 'isNull' and 'nullify' members would, for example, block
Nullable!int's 'isNull' and 'nullify' members. Would '__isNull' '__nullify' be
acceptable? Alternatively, I could special case opAssign and opEquals: 'var =
Variant.NULL' and 'var == Variant.NULL'. Thoughts?
Sorry for all the questions, but I want to make sure what I build is what you
need. That said, I'm petty sure I can incorporate what you want.
