I drew an 'inheritance tree' for the types used in D.
It might be an idea to use something like this for
a type of generics?

It is a combination of the type categories idea I
mentioned in another thread, and the common idea
of inheritance in class libraries, where there is
one root class, Object. This is very convenient
for doing 'generics' on objects, why not extend
it to all variables?

I do not know if something like this has ever been
done in other languages, or if it is even feasible.
Anyway, here it is, have a look if you will:


+-- Variable
     +-- void
     +-- Boolean
     |    +-- bit
     |
     +-- Character
     |    +-- char
     |    +-- wchar
     |
     +-- Number
     |    +-- imaginary
     |    +-- complex
     |    +-- Real
     |    |    +-- float
     |    |    +-- double
     |    |    +-- extended
     |    |
     |    +-- Integral
     |         +-- Signed
     |         |    +-- byte
     |         |    +-- short
     |         |    +-- int
     |         |    +-- long
     |         |    +-- cent
     |         |
     |         +-- Unsigned
     |              +-- ubyte
     |              +-- ushort
     |              +-- uint
     |              +-- ulong
     |              +-- ucent
     |
     +-- Pointer
     |    +-- void *
     |    +-- char *
     |    +-- etc, etc...
     |
     +-- Delegate
     |    +-- FunctionPointer
     |
     +-- Array
     |
     +-- Struct
     |    +-- Structs...
     |
     +-- Class
     |    +-- Object
     |         +-- Loads
     |         +-- Of
     |         +-- Classes...
     |
     +-- Interface
          +-- IUnknown
          |    +-- COM Interfaces...
          |
          +-- Other Interfaces...



Comments, suggestions?

--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

I don't have any concrete use for this yet, but it is an intriguing brainstorm, and as such I think we should bat it around a bit and see if anything falls out.

First a couple of nitpicks:
    * Add unions (in a family with structs?)
    * Classes and Interfaces should be in a family, I would think

Now a couple of things of note:
    * It should be noted that this is a "recursive tree" - at various
points in the tree, the nodes (elements of an array, members of a
struct, etc.) contain the full tree within themselves.  Thus, we can
never represent the entire tree, fully expanded...nor can we enumerate
the possible types.  Any representation of a type in this tree must
account for arbitrarily deep levels of recursion.
    * How generics perform depends greatly on the (inherited) properties
of the various leaves of this tree.  I have no idea what this might mean
for generics.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CD817FE.8B1043DA@deming-os.org...
> I don't have any concrete use for this yet, but it is an intriguing brainstorm, and as such I think we should bat it around a bit and see if anything falls out.
>
> First a couple of nitpicks:
>     * Add unions (in a family with structs?)

Oops, I knew I forgot something!  :)


>     * Classes and Interfaces should be in a family, I would think
>

I actually pondered over placing Interfaces and structs in the same family, but I finally felt that this is just an implementation detail, and from a conceptual perspective they have nothing to do with each other.


> Now a couple of things of note:
>     * It should be noted that this is a "recursive tree" - at various
> points in the tree, the nodes (elements of an array, members of a
> struct, etc.) contain the full tree within themselves.  Thus, we can
> never represent the entire tree, fully expanded...nor can we enumerate
> the possible types.  Any representation of a type in this tree must
> account for arbitrarily deep levels of recursion.

Mmm....
Do you mean because you can have arrays that contain arrays, classes that
contain structs which contain...etc?


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

OddesE wrote:

> Mmm....
> Do you mean because you can have arrays that contain arrays, classes that
> contain structs which contain...etc?

Right.  My gut tells me that this is something very important...but I don't know why.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]