Compiler as dll

Bill Baxter wbaxter at gmail.com
Fri Jan 30 20:08:04 PST 2009


On Sat, Jan 31, 2009 at 11:48 AM, Daniel Keep
<daniel.keep.lists at gmail.com> wrote:
>
>
> Bill Baxter wrote:
>> Does Tango's Variant have a fixed type?
>
> No; it's like Phobos'.
>
>> It seems the std2 Variant doesn't really care what the type of the
>> thing you stuff in it is, as long as it fits in the memory space
>> allotted.   How is that useful?   What's the use case for needing
>> something that can be either 2.4f or "fred"?    (Sorry I don't know
>> what a "CVar" system is...)
>
> Think about Quake, or anything based on Id's engines.  CVars are
> basically global variables you can set from the in-game console.  The
> original problem was this:
>
> "I want a hash indexed by string going to... um... er... anything!"
>
> And thus, Variant was born.  Incidentally, I've since changed to a
> design involving callbacks, so there you go.

Ok I see.

> I suppose that it's, in a way, like D's support for typesafe variadic
> functions; except it only takes one value. :P
>
>> What I actually needed was something
>> with a fixed, internal type that could expose its value in a flexible
>> way via templated get/set routines.  But for me a float property is
>> never going to mutate into a string property.
>>
>> --bb
>
> OK, your turn: why would you want something that wraps a single type in
> itself and has to be accessed via templates?  Couldn't you just... use
> the type you want with templates?

I'm using it like a property in a GUI.  The property is float or bool
or whatever, I just need to be able to get and set the value in some
generic way.  So at least it's gotta have conversions to and from
string -- to for showing in the GUI, from for turning the user's edit
back into a value.
And additionally it would be nice for it to not be too much a stickler
for exact type -- to be able to convert to and from int even if its
really a float, for example.

I thought that was the kind of problem Variant was supposed to solve,
but seems not quite so.  But my original vision was that the base
Property type would have template methods that pretty much like
Variant's.  get(T) opAssign(T).  I don't see how to make that work
without having a base class that contains the actual value in
somehting like a Variant.

So right now a sketch of the design is an abstract Property with
concrete Properties with specific type derived from that.  Like so:

class Property {
    Variant value;
    T get(T) { value.get!(T)(); }
    void opAssign(T)(T v) { value = v; }
    abstract void fromString(string str);
}

class PropertyT(T) : Property
{
     void fromString(string str) {  ... }
}

So really it's pretty much like your CVar case.  But the difference is
a Property should only be one particular thing for its entire life,
whereas the thing pointed to by "foo" in your hash map can change
type.

--bb



More information about the Digitalmars-d mailing list