Nick Sabalausky wrote:
> I'd rather have a type that all other types derive from. Sort of like "Object" (or is it "object"?), but serves as the base type for all types, not just classes. Not sure if this would be possible though (having vtables for every int and char in the program doesn't sound like a good idea ;) ).

This would be convenient. I think, if Walter were for this idea, it'd be implemented via automatic boxing. That gives you the efficiency of using int, double, and so forth directly on the hardware. (It's how C# does it.)

That said, I seriously doubt this will be a priority for Walter, ever.

Christian Kamm wrote:
> I had done something similar, albeit using D2 and traits, in
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=56018
> 
> It's good to see it's possible in D1! The main advantage of __traits seems
> to be that you can avoid building a lookup table and thereby simplify the
> user interface. On the other hand, your approach will probably work even
> when the extension methods are defined in different modules, as long as the
> one with the extensions mixin is imported?
> 

Yes.

The best solution IMHO would be to be able to declare things to be in the vtable that aren't functions (but are, for example, a pointer to some area of globally-accessible-and-writable memory). Then you could effectively have a sub-vtable. But alas, 'tis not possible :)

 - Gregor Richards

"Christopher Wright" <dhasenan@gmail.com> wrote in message news:ghgikj$2ckq$1@digitalmars.com...
> Nick Sabalausky wrote:
>> I'd rather have a type that all other types derive from. Sort of like
>> "Object" (or is it "object"?), but serves as the base type for all types,
>> not just classes. Not sure if this would be possible though (having
>> vtables
>> for every int and char in the program doesn't sound like a good idea
>> ;) ).
>
> This would be convenient. I think, if Walter were for this idea, it'd be implemented via automatic boxing. That gives you the efficiency of using int, double, and so forth directly on the hardware. (It's how C# does it.)
>
> That said, I seriously doubt this will be a priority for Walter, ever.

I came across a need for it in a command-line parser I'm writing, but ended up having to define a boxing class myself ("RefBox!(T)", which can then be cast to "Object", although I should probably create a special base class for all the "RefBox!(T)"'s) and use a string mixin to clean up usage. I would much rather use a standardized boxer though. A "dynamic/variant" type would probably work too, but I don't like doing any runtime type variance other than polymorphism and boxing. If anyone's interested, my code is attached. I think the only part of my util module this uses is "stformat()" which is nothing more than the following helper code for Tango's Layout!(T):

Layout!(char) stformat;
static this()
{
 stformat = new Layout!(char)();
}