NULL indicator in Variant

Steve Teale steve.teale at britseyeview.com
Sat Oct 29 13:23:11 PDT 2011


On Fri, 28 Oct 2011 23:50:37 -0400, Robert Jacques wrote:

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

Robert,

I read through my answers again, and they seem to me to be perfectly 
valid responses to your questions. It's just that you are insisting on 
the use of terms like nullify and isNull that have different semantics 
than what is actually needed to deal with the database situation. Yes, I 
know I used NULL in my original question, but I was at pains to back of 
from that in my responses to your questions.

I believe all that's needed to make variants play well with databases is 
a mark or flag. This could be used in other contexts for quite unrelated 
purposes. For the database case it would essentially serve as an ignore-
this-value-just-note-the-type flag.

It is not essential, but it would make a database interface using 
variants easier to code and to use. Probably we should just forget the 
idea.

Steve


More information about the Digitalmars-d mailing list