NULL indicator in Variant

[Steve Teale]

On Fri, 28 Oct 2011 00:35:45 -0400, Robert Jacques wrote:

> On Thu, 27 Oct 2011 14:06:47 -0400, Steve Teale
> <steve.teale at britseyeview.com> wrote:
>> On Thu, 27 Oct 2011 13:58:54 -0400, Steven Schveighoffer wrote:
>>> On Thu, 27 Oct 2011 13:53:02 -0400, Steve Teale
>>> <steve.teale at britseyeview.com> wrote:
>>>> On Thu, 27 Oct 2011 13:09:43 -0400, Steven Schveighoffer wrote:
>>>>> On Thu, 27 Oct 2011 12:58:57 -0400, Steve Teale
>>>>> <steve.teale at britseyeview.com> 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?

I want to be able to mark a Variant which is otherwise functional and 
representing a type. It might have the .init value for the type, or it 
could have any other value. The mark in my context would signify that it 
should be treated as a NULL for database purposes. But it could be used 
to add any other subtlety to a variant. It's just a mark I think.

> 
> Does nullifying a value wipe it clean? i.e. can you ever un-nullify
> something?

No, it's just a mark, you can wipe it off and it then reverts to being a 
perfectly normal variant

> If you assign to a nulled variant, should there be some sort of special
> behavior?
>

I think maybe it should wipe the mark. If I've chosen a particular 
variant in a particular state to mark, then I'd say the mark would lose 
its significance if the thing was radically changed.
 
> Should 'hasValue' return false or true? If true, what should 'get' &
> company return?

I think hasValue() et al should behave as usual - after all, it's just a 
mark. It's what I choose to do with the value from get or whatever that 
should be influenced.

> 'type' should return the TypeInfo of the type that was nullified,
> correct

Absolutely - that's the primary requirement for me. That the variant 
should carry its type information, but not necessarily have a useful 
value.

> What should 'toString' return?
> 

Following my current path, it should return what it would normally 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?

Avoid the word null - use mark or whatever. If adding it means earmarking 
more than a single bit, then make it 'flags'. That way the facility is 
quite general-purpose. I think that in a 'type' that is supposed to stand 
for almost anything, this is not out of place.

> Sorry for all the questions, but I want to make sure what I build is
> what you need. That said, I'm pretty sure I can incorporate what you
> want.

Questions are good. Do my answers make any sense?

Steve