On Sat, 29 Oct 2011 16:23:11 -0400, Steve Teale <[email protected]>
wrote:
On Fri, 28 Oct 2011 23:50:37 -0400, Robert Jacques wrote:
[snip]
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.
Steve, when you state: "For the database case it would essentially serve as an
ignore-this-value-just-note-the-type flag", you are no longer describing your
concept or use case, you are describing how you would implement that use case using
functionality X.
From what I can tell, you're thinking of an implementation like this:
Variant var = 1;
var.mark = true;
if(var.mark) {
// Do DB NULL stuff
} else {
// Do DB value stuff
}
But how is that different from this:
Variant var = 1;
var.nullify;
if(var.isNull) {
// Do DB NULL stuff
} else {
// Do DB value stuff
}
or this:
auto var = Variant.NULL!int;
if(var.hasValue) {
// Do DB NULL stuff
} else {
// Do DB value stuff
}
or this:
auto var = typeid(int);
if(auto type = var.peek!TypeInfo) {
// Do DB NULL stuff
} else {
// Do DB value stuff
}
?
I don't care about adding functionality X; you can already build a null-able DB
type on top of Variant (see above, or use Nullable!Vairant, etc). I care about
making variant (or Algebraic) _into_ a null-able DB type. So that it composes
integrates well with the rest of our code-bases.
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
Databases and their ilk are a pretty big and important use case. So I think
cleanly supporting them is necessary. That said, there are lots of alternatives
available.
