On Fri, 28 Oct 2011 00:35:45 -0400, Robert Jacques wrote: > On Thu, 27 Oct 2011 14:06:47 -0400, Steve Teale > <[email protected]> wrote: >> On Thu, 27 Oct 2011 13:58:54 -0400, Steven Schveighoffer wrote: >>> On Thu, 27 Oct 2011 13:53:02 -0400, Steve Teale >>> <[email protected]> wrote: >>>> On Thu, 27 Oct 2011 13:09:43 -0400, Steven Schveighoffer wrote: >>>>> On Thu, 27 Oct 2011 12:58:57 -0400, Steve Teale >>>>> <[email protected]> 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
