Ilya Minkov <minkov@cs.tum.edu> wrote:

> Good that you looked. I looked a bit through the compiler source and it really seems to lack it these days.

Yes, I think it's not on the agenda for D 1.0.

> I'm sorry i deceived you all.

Hey, no sweat. It wasn't intentional, now was it? :-)

-- 
dave

> Well, I think reflection, as implemented in Java or .NET (I mean creating and executing code at runtime), isn't that important for D right now, but class meta-data is. Also, don't think it's that hard for Walter to do it, but he probably want D as it is right now for the 1.0 release.

Yes, that's what I mean.  Reflection usually refers to metadata plus the capability to create code at run-time.  Introspection usually refers to merely metadata.  I use the term reflection loosely because its the popular term to use.  Introspection is probably what I should have said. Introspection is the one that makes my mouth water.  Full reflection is too much for my little brain to handle at the moment.  I would be VERY pleased with merely metadata.

Craig

Craig Black wrote:
> It sounds like reflection (a.k.a. introspection) is taking a backseat to the
> many other features that have been added.  Does anyone realize the power of
> class meta-data at run-time?  It's huge!

Do you realize the memory space requirements of the full symbol table that it takes to do full introspection at run-time?  It's huge!

:-)

I for one would not support automatic inclusion of full introspection to D.

  It's a whole new programming
> paradigm!

Yes, and it's not the domain of *compiled* *to* *machine* *code* languages.


> I could give you many examples of how I would use it if anyone
> cared to listen to me rant.
> 
> I am very interested in D and all of its innovate features, but for my
> purposes it would not be a vast improvement over C++ if reflection were
> absent.  Maybe I'm all by myself in saying this, but I would use D if it
> included reflection.  I could not justify porting from C++ otherwise.
> 
> I would REALLY like to know what Walter intends to do regarding reflection.

Frankly, Java's just sitting there, ready for your use where you need full introspction and reflection.  Or perhaps Python.  But please don't engorge compiled languages with full run-time symbol tables - at least, not by default.

(I'd have no arguments if Walter wanted to offer a class definition modifier saying "this class is fully introspective," at which point it could emit symbol table stuff into the object files.  But please, not ALL THE TIME.)

Richard Krehbiel schrieb:
> I for one would not support automatic inclusion of full introspection to D.

Perhaps automatic for fields (because often the whole hierarchy has to be serialized) and non-automatic for methods? Method data would also tend to be much larger than field data, i think.

Syntactically, inclusion of such information with classes can be done by inheriting them from a "magic" interface which would also be used to access it. Actually, even field data can be placed optionally this way since it's so simple to use.

>>   It's a whole new programming paradigm!
> 
> Yes, and it's not the domain of *compiled* *to* *machine* *code* languages.

Which leads me to an idea of companion scripting language to D, which should allow easy combination of scripted and native code. But that's a whole new direction of work! And hey, it would need near to full introspection capabilities in the compiled part of D.

-eye

"Craig Black" <cblack@ara.com> wrote in message news:c49mja$2tc4$1@digitaldaemon.com...
> I would REALLY like to know what Walter intends to do regarding
reflection.

I do intend to expand the 'classinfo' so that one could figure out all the fields and methods of a class. However, I spent some time trying to figure out how to make dynamic class loading work with some special compiler magic, but it isn't going to happen. The stumbling block is not knowing at compile time what the type of an expression is.

I could wave the magic spec wand and say that all methods in a dynamic class must return void and that data fields are not possible, but such restrictions make it not so useful.

Walter wrote:

>"Craig Black" <cblack@ara.com> wrote in message
>news:c49mja$2tc4$1@digitaldaemon.com...
>  
>
>>I would REALLY like to know what Walter intends to do regarding
>>    
>>
>reflection.
>
>I do intend to expand the 'classinfo' so that one could figure out all the
>fields and methods of a class. However, I spent some time trying to figure
>out how to make dynamic class loading work with some special compiler magic,
>but it isn't going to happen. The stumbling block is not knowing at compile
>time what the type of an expression is.
>
>I could wave the magic spec wand and say that all methods in a dynamic class
>must return void and that data fields are not possible, but such
>restrictions make it not so useful.
>  
>
Thanks Walter, this explains a lot. I'm going to add it to the RTTI section in the wiki.

http://www.prowiki.org/wiki4d/wiki.cgi?HowTo/RealtimeTypeInformation

-- 
-Anderson: http://badmama.com.au/~anderson/

> I do intend to expand the 'classinfo' so that one could figure out all the fields and methods of a class.

Super-de-duper! What version do you forsee as having these capabilities?

>However, I spent some time trying to figure
> out how to make dynamic class loading work with some special compiler
magic,
> but it isn't going to happen. The stumbling block is not knowing at
compile
> time what the type of an expression is.

"Dynamic class loading"?  You're talking about loading a class from a DLLat run-time, right?  I don't really understand your problem.  Perhaps I have a different idea about what "dynamic class loading" is.

> I could wave the magic spec wand and say that all methods in a dynamic
class
> must return void and that data fields are not possible, but such restrictions make it not so useful.

Again I don't understand your dilemma.  Perhaps, if you have time, you could expound on it.

Thanks,

Craig

Walter 提到:

> "Craig Black" <cblack@ara.com> wrote in message news:c49mja$2tc4$1@digitaldaemon.com...
> 
>>I would REALLY like to know what Walter intends to do regarding
> 
> reflection.
> 
> I do intend to expand the 'classinfo' so that one could figure out all the fields and methods of a class. However, I spent some time trying to figure out how to make dynamic class loading work with some special compiler magic, but it isn't going to happen. The stumbling block is not knowing at compile time what the type of an expression is.
> 
> I could wave the magic spec wand and say that all methods in a dynamic class must return void and that data fields are not possible, but such restrictions make it not so useful.
> 
> 
I found a C++ version of reflection (they called it AS IS). Check it @ http://reflection.sourceforge.net/
-- 
School, yet another nickname for anonymous.
:D ;-D

"Craig Black" <cblack@ara.com> wrote in message news:c572ms$j7c$1@digitaldaemon.com...
> > I do intend to expand the 'classinfo' so that one could figure out all
the
> > fields and methods of a class.
>
> Super-de-duper! What version do you forsee as having these capabilities?

2.0.

> >However, I spent some time trying to figure
> > out how to make dynamic class loading work with some special compiler
> magic,
> > but it isn't going to happen. The stumbling block is not knowing at
> compile
> > time what the type of an expression is.
> "Dynamic class loading"?  You're talking about loading a class from a
DLLat
> run-time, right?  I don't really understand your problem.  Perhaps I have
a
> different idea about what "dynamic class loading" is.

I mean given the name of a class, load it at runtime from some external database (like a DLL), create an instance of that class, and then access its members.

> > I could wave the magic spec wand and say that all methods in a dynamic
> class
> > must return void and that data fields are not possible, but such restrictions make it not so useful.
>
> Again I don't understand your dilemma.  Perhaps, if you have time, you
could
> expound on it.

Object o = classFactory("TheNameOfSomeClassNotKnownAtCompileTime");
int a = o.x + o.y;

At runtime we can determine if the fields x and y are present, and what their types are. But we don't know how to compile the + expression, since we don't know the types of x and y at compile time. Think of how this would impact function overloading, for example:

    foo(o.x);

On Mon, 09 Aug 2004 16:15:03 -0700, Walter wrote:

> 
> "Craig Black" <cblack@ara.com> wrote in message news:c572ms$j7c$1@digitaldaemon.com...
>> > I do intend to expand the 'classinfo' so that one could figure out all
> the
>> > fields and methods of a class.
>>
>> Super-de-duper! What version do you forsee as having these capabilities?
> 
> 2.0.
> 
>> >However, I spent some time trying to figure
>> > out how to make dynamic class loading work with some special compiler
>> magic,
>> > but it isn't going to happen. The stumbling block is not knowing at
>> compile
>> > time what the type of an expression is.
>> "Dynamic class loading"?  You're talking about loading a class from a
> DLLat
>> run-time, right?  I don't really understand your problem.  Perhaps I have
> a
>> different idea about what "dynamic class loading" is.
> 
> I mean given the name of a class, load it at runtime from some external database (like a DLL), create an instance of that class, and then access its members.
> 
>> > I could wave the magic spec wand and say that all methods in a dynamic
>> class
>> > must return void and that data fields are not possible, but such restrictions make it not so useful.
>>
>> Again I don't understand your dilemma.  Perhaps, if you have time, you
> could
>> expound on it.
> 
> Object o = classFactory("TheNameOfSomeClassNotKnownAtCompileTime");
> int a = o.x + o.y;

Something like this isn't a problem with classes, but rather a typing issue, and (obviously) the way to resolve it is using a cast.  For instance if you were to provide a classFactory method, one would then do:

Object o = classFactory("TheNameOfSomeClassNotKnownAtCompileTime");
MyInterface a = cast(MyInterface)o;
if (a is null)
	throw new Exception("Bad Class");

Casting is probably the most consistent method of doing anything like this- you even have to cast with Reflection in Java- and I really like the way they do it.

For those of you who aren't familiar, in Java for each class you write,
there is a Class class as well.  That is to say, one can get a Class
object representing your class.  One of that Object's fields is an array
of Constructor objects (one can even do a Class.getConstructor(Class[]
parameterTypes) which was a HUGE pain before Java got autoboxing in 1.5).
Once one has a Constructor, run this on the constructor object:
"Object newInstance(Object[] initargs) " <- right out of JDocs.

One can also do similar things with Method objects in Java.

I'm sure that Walter has thought of simply casting, but has a better method (as he frequently does) although I'm having trouble imagining any other method that is type-safe.  So the question is... what'cha got brewing up there, Walter?

John