As I mentioned here and described on d.gnu, I'm working on a port of DMD to Linux.  The big part of the work is complete, so now I'm playing with a more complete TypeInfo/ClassInfo, and I'm wondering what people concretely want from introspection.  Specific things you've needed to do that have been stymied by C and C++'s opacity, or things from other languages with introspection that you've found helpful.

Some way to get a unique ID for each class, preferrably one that won't
change on a recompile (i.e. based on the class name) and also preferrably
short (32 bits maybe).  For persistence.

A way to look up a classinfo given its unique ID.

Some way to create a new instance of a class given its classinfo.  It would likely only be able to call a default constructor (one with no parameters).

Given those 3 things, implementing persistence ourselves is easy.  With access to the class name, #1 can be done user side (though it may as well be done during compile time automatically).  #2 could be done with an associative array on the user side, and #3 could be implemented user side as well (but it wouldn't be nearly so nice; it'd have to be grafted into each class via some kind of factory function lookup.  Am I just lazy or what? The class name should have full scope including module name available so you can tell classes with the same name in different modules apart from each other.  And ID collisions could be problematic too, though unlikely.  Even for a program with 10000 classes, the likelihood of a collision would be low if the hash is good.

Test for IsA (is instance of A) and IsDerivedFromA (is instance of A or is
instance of class derived from A)

Of course dynamic cast.

Scripting support is easier if you can examine members and get # and types of parameters to each function.  But I can live without that.

I'm sure there are some more.

Sean

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D4E1F35.5000703@users.sourceforge.net...
> As I mentioned here and described on d.gnu, I'm working on a port of DMD to Linux.  The big part of the work is complete, so now I'm playing with a more complete TypeInfo/ClassInfo, and I'm wondering what people concretely want from introspection.  Specific things you've needed to do that have been stymied by C and C++'s opacity, or things from other languages with introspection that you've found helpful.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D4E1F35.5000703@users.sourceforge.net...
> As I mentioned here and described on d.gnu, I'm working on a port of DMD to Linux.  The big part of the work is complete, so now I'm playing with a more complete TypeInfo/ClassInfo, and I'm wondering what people concretely want from introspection.  Specific things you've needed to do that have been stymied by C and C++'s opacity, or things from other languages with introspection that you've found helpful.

I for one specifically do NOT want complete introspection; this is a feature for interpreted (or nearly) languages.  A means for a programmer to label specific classes as "serializable" might be nice, but I don't want D to become so unweildy that executables carry around a massive type database.

C++'s RTTI is just about right.  You can ask if a pointer is to a class of a certain type, or is derived from a certain type.  Run-time support is all there using the vtable pointer, which object instances must carry around anyway.

Most of the type info should *stay* in the compiler, and *not* be added to the executable, except if the programmer asks for it.

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net  (personal)

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ailcd5$1cfq$1@digitaldaemon.com...
> Some way to get a unique ID for each class, preferrably one that won't
> change on a recompile (i.e. based on the class name) and also preferrably
> short (32 bits maybe).  For persistence.
>
> A way to look up a classinfo given its unique ID.

What's wrong with the 128-bit GUID concept?

> Scripting support is easier if you can examine members and get # and types of parameters to each function.  But I can live without that.

Good.  D isn't a scripting language, it's for generating optimized machine code.

I still believe that the symbol tables (number of class members, names, types, etc) should be available to a D programmer using a compile-time macro language, and I really don't think executables should be burdened with this stuff.

On Mon, 5 Aug 2002 01:26:38 -0700 "Sean L. Palmer" <seanpalmer@earthlink.net> wrote:

> Test for IsA (is instance of A) and IsDerivedFromA (is instance of A or is
> instance of class derived from A)

Very easy to write even now. Just look at ClassInfo;

> Of course dynamic cast.

All reference casts in D are dynamic.

On Mon, 5 Aug 2002 07:39:34 -0400 "Richard Krehbiel" <rich@kastle.com> wrote:

>> A way to look up a classinfo given its unique ID.
> 
> What's wrong with the 128-bit GUID concept?

Wouldn't it be simplier for the compiler to assign a unique integer to each
class declared in the program? 4 times smaller, and much faster when it
comes to comparison.

Burton Radons <loth@users.sourceforge.net> wrote in news:3D4E1F35.5000703 @users.sourceforge.net:

> As I mentioned here and described on d.gnu, I'm working on a port of
DMD
> to Linux.  The big part of the work is complete, so now I'm playing
with
> a more complete TypeInfo/ClassInfo, and I'm wondering what people concretely want from introspection.  Specific things you've needed to
do
> that have been stymied by C and C++'s opacity, or things from other languages with introspection that you've found helpful.
> 

For those that are complaining about addtional executable bulk I suggest a compile option to excude introspection information.

However I can find use for both introspection of member variables and of functions.

Introspection of member variables in useful for lots of things. I've used in in Python to build automatic persistance.  I have also used to automatically tie database fields to object members.

There are a couple of reasons why I want to be able to inspect objects for functions.  It would provide support similar to Java Beans for code building tools.  Second it would make it much easier to attach D to various scripting engines.

On a personal side I have a library that builds GUIs on the fly via a GUI description language.  The code and language have gone thru several incarnations.  One of the things I'd like to do in the D version is reference callback functions from directly within the GUI language.

<button text="Ok" OnClick="DoOkClick()" />

On Mon, 5 Aug 2002 13:34:38 +0000 (UTC) Patrick Down <pat@codemoon.com> wrote:

> Introspection of member variables in useful for lots of things. I've used in in Python to build automatic persistance.  I have also used to automatically tie database fields to object members.

Python is an interpreted language. D is not.

> There are a couple of reasons why I want to be able to inspect objects for functions.  It would provide support similar to Java Beans for code building tools.  Second it would make it much easier to attach D to various scripting engines.
> 
> On a personal side I have a library that builds GUIs on the fly via a GUI description language.  The code and language have gone thru several incarnations.  One of the things I'd like to do in the D version is reference callback functions from directly within the GUI language.
> 
> <button text="Ok" OnClick="DoOkClick()" />

This can be done in a better way - look at Delphi for an example.
There, you can declare properties and methods of class as "published",
which means that information about them is saved. So, typically
properties of GUI components like width, height, caption etc are
all declared as published, so GUI designer can see them, and you
declare event handlers as published so symbolic names can later
be used.

Pavel Minayev <evilone@omen.ru> wrote in news:CFN374737995338773@news.digitalmars.com:

> On Mon, 5 Aug 2002 13:34:38 +0000 (UTC) Patrick Down
> <pat@codemoon.com> wrote:
> 
>> Introspection of member variables in useful for lots of things. I've used in in Python to build automatic persistance.  I have also used to automatically tie database fields to object members.
> 
> Python is an interpreted language. D is not.

So? Does this mean that D should not have introspection so that
you can do similar things?  I'm not asking for run time modifiable
code or structures.  I'm just asking to be able to list the names and
types of members.

>> On a personal side I have a library that builds GUIs on the fly via a GUI description language.  The code and language have gone thru several incarnations.  One of the things I'd like to do in the D version is reference callback functions from directly within the GUI language.
>> 
>> <button text="Ok" OnClick="DoOkClick()" />
> 
> This can be done in a better way - look at Delphi for an example.
> There, you can declare properties and methods of class as "published",
> which means that information about them is saved. So, typically
> properties of GUI components like width, height, caption etc are
> all declared as published, so GUI designer can see them, and you
> declare event handlers as published so symbolic names can later
> be used.

Ok, I can see this as useful but it really just seems like introspection where the user can turn it on and off at the function and member level.

Don't want it to change on recompile (breaks existing data files).  So it should be some kind of hash on the name.

Sean

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN37473681461331@news.digitalmars.com...
> On Mon, 5 Aug 2002 07:39:34 -0400 "Richard Krehbiel" <rich@kastle.com>
wrote:
>
> >> A way to look up a classinfo given its unique ID.
> >
> > What's wrong with the 128-bit GUID concept?
>
> Wouldn't it be simplier for the compiler to assign a unique integer to
each
> class declared in the program? 4 times smaller, and much faster when it comes to comparison.