NULL indicator in Variant

[Robert Jacques]

On Fri, 28 Oct 2011 10:22:37 -0400, Steve Teale <steve.teale at britseyeview.com> wrote:
> On Fri, 28 Oct 2011 00:35:45 -0400, Robert Jacques wrote:

[snip]

>> 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

Okay, I think there was a bit of mis-communication here. What I'm asking is if the following represents required functionality:

Variant var = 1;
assert(var == 1);
var.nullify;
assert(var.isNull);
var.unnullify;
assert(var == 1);

That is, do you need to be able to recover the previous value of the variant once it has been nulled?

>> 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.

So would the following be correct behavior?

Variant var = 1;
assert(var == 1);
var.nullify;
assert(var.isNull);
var = "Hello";
assert(var == "Hello");
assert(var.isNull == false);

>> 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.

As far as I understand it, a database null means that the field has no value. If a nulled variant has no value what does 'get' return? And whatever it does return, how can that be logically correct?

>> '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.

If variant does 'not necessarily have a useful value', why should 'hasValue' et al. function as if there were a value?

>> What should 'toString' return?
>>
>
> Following my current path, it should return what it would normally return.

So

Variant var = 5;
var.nullify;
assert(var.toString == "5");

and not

assert(var.toString == "Nulled int";

?

>> 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?

Yes, but your answers weren't for the questions I was asking. Each of your answers appears to be predicated on a particular solution you wish to used to solve your problem. I've tried to ask clarifying questions to help define your actual use cases and functional needs. What I'm trying to define is the minimal feature set you need to make databases work well, not the behavior of the implementation you envision.