On Fri, 28 Oct 2011 10:22:37 -0400, Steve Teale <[email protected]>
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.
