I thought I remember reading somewhere in the documentation that
D would support some degree of reflection like Java. ( The ablility
to inspect classes and structures at runtime to see the names, position
and types of their members. ) But I can't find it though. Perhaps it
was mentioned in the forums.  I hope this is true.  I think this is a
usefull feature.

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns91E7AB18DAABBpatcodemooncom@63.105.9.61...
>
> I thought I remember reading somewhere in the documentation that
> D would support some degree of reflection like Java. ( The ablility
> to inspect classes and structures at runtime to see the names, position
> and types of their members. ) But I can't find it though. Perhaps it
> was mentioned in the forums.  I hope this is true.  I think this is a
> usefull feature.

It isn't there now, but it is anticipated to become part of the ClassInfo object that is available for each class type.

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns91E7AB18DAABBpatcodemooncom@63.105.9.61...
>
> I thought I remember reading somewhere in the documentation that
> D would support some degree of reflection like Java. ( The ablility
> to inspect classes and structures at runtime to see the names, position
> and types of their members. ) But I can't find it though. Perhaps it

I guess you won't see that for structures, since they are supposed to be lightweight; but for classes, there's ClassInfo, which already provides some useful information, like class name, its interfaces, and base class.

If only we could construct an object by ClassInfo... (hint, hint!) =)

"Pavel Minayev" <evilone@omen.ru> wrote in news:a8lrrc$25l5$2@digitaldaemon.com:

> "Patrick Down" <pat@codemoon.com> wrote in message news:Xns91E7AB18DAABBpatcodemooncom@63.105.9.61...
>>
>> I thought I remember reading somewhere in the documentation that
>> D would support some degree of reflection like Java. ( The ablility
>> to inspect classes and structures at runtime to see the names,
>> position and types of their members. ) But I can't find it though.
>> Perhaps it
> 
> I guess you won't see that for structures, since they are supposed to be lightweight; but for classes, there's ClassInfo, which already provides some useful information, like class name, its interfaces, and base class.

I think that there needs to be some way to access this information for structures too.  I think I remember Walter saying that he wants to use this information for optimizing the garbage collector and it's possible for strutures to have Object references too.

Also to build things like an automatic object persistance you need to be able to completely navigate stuctures as well as classes.

> 
> If only we could construct an object by ClassInfo... (hint, hint!) =)
> 

I'd vote for that too.

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns91E7E72FCA314patcodemooncom@63.105.9.61...

> I think that there needs to be some way to access this information for structures too.  I think I remember Walter saying that he wants to use this information for optimizing the garbage collector and it's possible for strutures to have Object references too.

Well, structures can contain references to Object, so what? Adding classinfo pointer to each structure would alse make them incompatible with the API, since it expects normal C structs.

> Also to build things like an automatic object persistance you need to be able to completely navigate stuctures as well as classes.

I guess structures are better copied byte-by-byte, while classes would be more complicated. Those rare cases when struct contains reference to object don't worth the thing - if you really need it to be persistent, make it class, not struct.

I think the problem here is with the fact (From what I understood)

that there is no headers (.h) files in D.
Imagine you have a commercial library. If you do not have headers (and
you don't want to give the source code) there must be a way to the
programmer to know the functions, classes and structures in the library.
You may give it in the documentation, but it do not work for a RAD tool
with code completation (that is the best feature in those tools).
For what I see were you must rely all public interfaces in classes (for those will be possible for acess member information)
(I'm not saying thats a bad strategy)

"Nuno Nunes" <nachn@altagis.biz> wrote in message news:3CAF05AC.6030007@altagis.biz...
>
>  I think the problem here is with the fact (From what I understood)
>
> that there is no headers (.h) files in D.
> Imagine you have a commercial library. If you do not have headers (and
> you don't want to give the source code) there must be a way to the
> programmer to know the functions, classes and structures in the library.
> You may give it in the documentation, but it do not work for a RAD tool
> with code completation (that is the best feature in those tools).


I wouldn't call class completion, no matter how much I
like it, the best feature of Delphi...  :)


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

"Pavel Minayev" <evilone@omen.ru> wrote in news:a8mk9t$n95$1 @digitaldaemon.com:

> "Patrick Down" <pat@codemoon.com> wrote in message news:Xns91E7E72FCA314patcodemooncom@63.105.9.61...
> 
> Adding classinfo pointer to each structure would alse make them incompatible with the API, since it expects normal C structs.

The information can be made available without doing anything to make stuctures incompatable.  Unlike class references the compiler knows the real type of a stucture in all instances so a structure does not need to carry a extra pointer to a ClassInfo like classes do. All that is needed is a little extra atribute to access the information.

struct Abc
{
}

Abc astruct;
ClassInfo b = astruct.type;

In the line above the compiler knows that astruct is of type Abc so just subsitutes the pointer to Abc's ClassInfo in place of atruct.type.

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a8n4sq$19ub$1@digitaldaemon.com...

> I wouldn't call class completion, no matter how much I
> like it, the best feature of Delphi...  :)

Why not?

By the way, Delphi is just an example of such approach - there are no
headers there, and units can be in compiled form - and still you
get the CodeComplete working. The solution is to store information
about types and functions, probably in some binary form (or XML?) in a
separate
file, generated by the compiler when it processes the module. So,
for each module, you get an .obj with the code in it, and, say,
a .dmi (D module interface) with all public members listed. Then,
both the compiler and the IDE can rely on information in this file.

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns91E86C7657A97patcodemooncom@63.105.9.61...

> All that is needed is a little extra atribute to access the information.

You are of course right. I should have thought a bit more about this =)

> struct Abc
> {
> }
>
> Abc astruct;
> ClassInfo b = astruct.type;

Since ClassInfo is class-specific and contains fields like destructor and
vtbl[],
it's probably better to define another class just for structs:

    class StructInfo
    {
        struct FieldInfo
        {
            char[] name;
            uint offset;
            ...
        }

        char[] name;
        uint[FieldInfo] fields;
    }

And then:

    Foo foo;
    StructInfo fooinfo = foo.structinfo;