TypeInfoEx and Variant: suggestions?

[Christopher Wright]

Daniel Keep wrote:
> 
> Christopher Wright wrote:
>> Daniel Keep wrote:
>>> Use the Tango Variant code.  It supports values of any size and doesn't
>>> require knowledge of the compile-time type.
>> Not so. That was one of three reasons that I wrote my own Variant
>> previously (the others being toString and sameness comparison).
> 
> What not so?  I know for a fact it supports values of any size, so I
> assume you're referring to compile-time.  With the new patch you can
> pack and unpack Variants from TypeInfo and a void* so you DON'T need to
> know the type ahead of time.  There isn't a way to construct from a
> single TypeInfo,void* pair since I wasn't sure if that would actually be
> needed.

Okay, you must have done that very recently, since I can't find it in my 
working copy.

> toString is a design issue, not a technical one; they didn't want stuff
> in tango.core depending on stuff outside of that.  If you look at the
> history of Variant, there's an old version with "proper" toString code
> that should port forward painlessly.

Yes, I'm familiar with that issue. I'm not faulting Tango for lacking a 
proper toString, but it was a problem, one that I couldn't work around 
with Tango's Variant, so I did what I had to do.

> On a side note, I'm working on getting Tango's Layout to understand
> Variants and do the "proper" stringification.  Still trying to work out
> how to get the changes to compile without having to rebuild Tango...
> *grumble*
> 
> As for comparisons, it supports opEqual and opCmp between Variants, it
> just doesn't attempt to do any automatic conversion between
> non-identical but comparable types (like comparing ints to longs.)

Ah. Mine does that -- it stores all floating point types as reals, for 
instance, and all integer types as longs (except for ulongs).

> Is there something specific you think Tango's Variant should do that it
> doesn't?

Apparently, nothing that won't be in the next release, aside from 
bitwise comparisons.

>   -- Daniel