Andrei Alexandrescu wrote:
> grauzone wrote:
>> For classes and structs, this is already possible: typeof(this).stringof
> 
> Not outside of a member function. This is crippling my Visitor implementation.

I use it in static constructors. If it doesn't work, well, that's news to me.

I don't know about "typeof(this) property;", though. I never tried it.

>> Now we only need a way to get some kind of compile time object for functions and modules (like the type for classes/structs). Then you simply can use .stringof on them.
> 
> There's much more to reflection that we need to define.

Runtime as well as compile time.

Edward Diener wrote:
> I argued for this in the past on this NG but still no one seems to have picked up the idea that a full reflection library for D, supported fully by the compiler, would be a great thing. It would also allow RAD programming with D outside of the functionality one could use in 3rd party tools designed around full run-time reflection capabilities.

D2 will have reflection. (Walter doesn't know yet. He thinks D3 will have reflection.) It will be compile-time reflection because only run-time reflection only is missing the point.

Andrei

Christopher Wright wrote:
> Andrei Alexandrescu wrote:
>> grauzone wrote:
>>> For classes and structs, this is already possible: typeof(this).stringof
>>
>> Not outside of a member function. This is crippling my Visitor implementation.
> 
> I use it in static constructors. If it doesn't work, well, that's news to me.
> 
> I don't know about "typeof(this) property;", though. I never tried it.
> 
>>> Now we only need a way to get some kind of compile time object for functions and modules (like the type for classes/structs). Then you simply can use .stringof on them.
>>
>> There's much more to reflection that we need to define.
> 
> Runtime as well as compile time.

Compile-time. Runtime follows and only needs a little glue.

Andrei

On Sat, Feb 28, 2009 at 10:49 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> Edward Diener wrote:
>>
>> I argued for this in the past on this NG but still no one seems to have picked up the idea that a full reflection library for D, supported fully by the compiler, would be a great thing. It would also allow RAD programming with D outside of the functionality one could use in 3rd party tools designed around full run-time reflection capabilities.
>
> D2 will have reflection. (Walter doesn't know yet. He thinks D3 will have reflection.) It will be compile-time reflection because only run-time reflection only is missing the point.

Will it be implemented through __traits, or *yet another* compile-time introspection facility?

Edward Diener wrote:
> I argued for this in the past on this NG but still no one seems to have picked up the idea that a full reflection library for D, supported fully by the compiler, would be a great thing. It would also allow RAD programming with D outside of the functionality one could use in 3rd party tools designed around full run-time reflection capabilities.

I believe it is a great idea, it's just that there are so many that I'm swamped.

Jarrett Billingsley wrote:
> On Sat, Feb 28, 2009 at 10:49 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>> Edward Diener wrote:
>>> I argued for this in the past on this NG but still no one seems to have
>>> picked up the idea that a full reflection library for D, supported fully by
>>> the compiler, would be a great thing. It would also allow RAD programming
>>> with D outside of the functionality one could use in 3rd party tools
>>> designed around full run-time reflection capabilities.
>> D2 will have reflection. (Walter doesn't know yet. He thinks D3 will have
>> reflection.) It will be compile-time reflection because only run-time
>> reflection only is missing the point.
> 
> Will it be implemented through __traits, or *yet another* compile-time
> introspection facility?

Whatever it'll be, I'm sure it will not shut off your whine noise generator :o).

Andrei

Andrei Alexandrescu wrote:
> Edward Diener wrote:
>> I argued for this in the past on this NG but still no one seems to have picked up the idea that a full reflection library for D, supported fully by the compiler, would be a great thing. It would also allow RAD programming with D outside of the functionality one could use in 3rd party tools designed around full run-time reflection capabilities.
> 
> D2 will have reflection. (Walter doesn't know yet. He thinks D3 will have reflection.) It will be compile-time reflection because only run-time reflection only is missing the point.

The whole debate about "compile-time" and "run-time" reflection  is irrelevant as long as one can invoke it without having to inject code into an already existing construct.

It must work through run-time code which can ask such reflection questions as: enumerate for me all of the classes in a particular module etc., or enumerate for me all the functions in a class etc. . It must work by allowing code from outside of a construct to query that construct and get its accessible constructs. How that run-time code is written, whether using "compile-time" reflection using templates, or run-time classes accessible from a library whose reflection data is produced by the D compiler, is not important from the user's point of view as long as the user has the access he wants and can write relatively clean and clear code to get it.

Of course from within any given construct one should also be able to write code in a clear manner which accesses the inner constructs.

Access to constructs via reflection should follow the same protection features as any other code, so that public constructs are always accessible but private constructs are only accessible following their normal rules.

So I do not know what you mean by "only run-time reflection only is missing the point" but certainly the ability to use reflection at run-time is vitally important from outside of a construct to any 3rd party tool which wants to introspect already existing constructs and create objects from those constructs based on the information run-time reflection can return.

Edward Diener wrote:
> Andrei Alexandrescu wrote:
>> Edward Diener wrote:
>>> I argued for this in the past on this NG but still no one seems to have picked up the idea that a full reflection library for D, supported fully by the compiler, would be a great thing. It would also allow RAD programming with D outside of the functionality one could use in 3rd party tools designed around full run-time reflection capabilities.
>>
>> D2 will have reflection. (Walter doesn't know yet. He thinks D3 will have reflection.) It will be compile-time reflection because only run-time reflection only is missing the point.
> 
> The whole debate about "compile-time" and "run-time" reflection  is irrelevant as long as one can invoke it without having to inject code into an already existing construct.
> 
> It must work through run-time code which can ask such reflection questions as: enumerate for me all of the classes in a particular module etc., or enumerate for me all the functions in a class etc. . It must work by allowing code from outside of a construct to query that construct and get its accessible constructs. How that run-time code is written, whether using "compile-time" reflection using templates, or run-time classes accessible from a library whose reflection data is produced by the D compiler, is not important from the user's point of view as long as the user has the access he wants and can write relatively clean and clear code to get it.
> 
> Of course from within any given construct one should also be able to write code in a clear manner which accesses the inner constructs.
> 
> Access to constructs via reflection should follow the same protection features as any other code, so that public constructs are always accessible but private constructs are only accessible following their normal rules.
> 
> So I do not know what you mean by "only run-time reflection only is missing the point" but certainly the ability to use reflection at run-time is vitally important from outside of a construct to any 3rd party tool which wants to introspect already existing constructs and create objects from those constructs based on the information run-time reflection can return.

This is a long discussion, but in brief any runtime reflection engine needs some sort of compile-time metadata infrastructure. Some languages don't make that accessible within the language itself. Runtime reflection has been explored extensively, its possibilities and limitations are pretty well understood, I hardly smothered a yawn reading all you wrote. Compile-time reflection is much less understood and hides many more exciting possibilities. With the advances in compiler technology implemented by Walter, we have a chance to tackle reflection in a systematic manner.

Andrei

Andrei Alexandrescu wrote:
> Christopher Wright wrote:
>> Andrei Alexandrescu wrote:
>>> grauzone wrote:
>>>> For classes and structs, this is already possible: typeof(this).stringof
>>>
>>> Not outside of a member function. This is crippling my Visitor implementation.
>>
>> I use it in static constructors. If it doesn't work, well, that's news to me.
>>
>> I don't know about "typeof(this) property;", though. I never tried it.
>>
>>>> Now we only need a way to get some kind of compile time object for functions and modules (like the type for classes/structs). Then you simply can use .stringof on them.
>>>
>>> There's much more to reflection that we need to define.
>>
>> Runtime as well as compile time.
> 
> Compile-time. Runtime follows and only needs a little glue.

That glue requires user intervention. Would you add "mixin(Reflect);" to every class you wrote? But even that isn't sufficient -- you would have to implement some interface indicating that this class has reflection information, and pass objects around via that interface rather than using Object.

There should be a way to suppress emitting complex reflection information -- a command-line flag and a pragma. But I think it's a bit much to ask users to mark every class they create in two different ways.

> Andrei

Andrei Alexandrescu wrote:
> Edward Diener wrote:
>> Andrei Alexandrescu wrote:
>>> Edward Diener wrote:
>>>> I argued for this in the past on this NG but still no one seems to have picked up the idea that a full reflection library for D, supported fully by the compiler, would be a great thing. It would also allow RAD programming with D outside of the functionality one could use in 3rd party tools designed around full run-time reflection capabilities.
>>>
>>> D2 will have reflection. (Walter doesn't know yet. He thinks D3 will have reflection.) It will be compile-time reflection because only run-time reflection only is missing the point.
>>
>> The whole debate about "compile-time" and "run-time" reflection  is irrelevant as long as one can invoke it without having to inject code into an already existing construct.
>>
>> It must work through run-time code which can ask such reflection questions as: enumerate for me all of the classes in a particular module etc., or enumerate for me all the functions in a class etc. . It must work by allowing code from outside of a construct to query that construct and get its accessible constructs. How that run-time code is written, whether using "compile-time" reflection using templates, or run-time classes accessible from a library whose reflection data is produced by the D compiler, is not important from the user's point of view as long as the user has the access he wants and can write relatively clean and clear code to get it.
>>
>> Of course from within any given construct one should also be able to write code in a clear manner which accesses the inner constructs.
>>
>> Access to constructs via reflection should follow the same protection features as any other code, so that public constructs are always accessible but private constructs are only accessible following their normal rules.
>>
>> So I do not know what you mean by "only run-time reflection only is missing the point" but certainly the ability to use reflection at run-time is vitally important from outside of a construct to any 3rd party tool which wants to introspect already existing constructs and create objects from those constructs based on the information run-time reflection can return.
> 
> This is a long discussion, but in brief any runtime reflection engine needs some sort of compile-time metadata infrastructure. Some languages don't make that accessible within the language itself. Runtime reflection has been explored extensively, its possibilities and limitations are pretty well understood, I hardly smothered a yawn reading all you wrote. 

It was written because I have inevitably seen discussions about language reflection mechanisms end with talk about really neat new compile-time facilities which bring one no closer to real run-time reflection than before.

>Compile-time reflection is much less understood 
> and hides many more exciting possibilities. With the advances in compiler technology implemented by Walter, we have a chance to tackle reflection in a systematic manner.

Good ! I look forward to seeing it and using it in D.