www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Reflection?

reply Sclytrack <sclytrack idiot.com> writes:
Instead of targeting doc files, could dmd create xml files
for the purpose of runtime reflection, instead of trying to
go to runtime reflection via __traits.

You can archive these files together with the binary code.
Create some sort of D package.

I mean C (GNOME) is going with xml files for their introspection.
http://library.gnome.org/devel/gi/unstable/gi-gir-reference.html

---------------------------------------------------------
dmd is a 42 bit compiler.
oh W. just added another bit.
dmd is now a 43 bit compiler.
---------------------------------------------------------
Oct 24 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 24 October 2010 12:17:47 Sclytrack wrote:
 Instead of targeting doc files, could dmd create xml files
 for the purpose of runtime reflection, instead of trying to
 go to runtime reflection via __traits.
 
 You can archive these files together with the binary code.
 Create some sort of D package.
 
 I mean C (GNOME) is going with xml files for their introspection.
 http://library.gnome.org/devel/gi/unstable/gi-gir-reference.html

__traits isn't runtime reflection. It's compile time reflection. It's highly useful in creating templates and string mixins and the like. If you want runtime reflection, it's possible to use __traits to put together a set of functions which hold the traits information to be queried at runtime, thereby creating your own runtime reflection mechanism (I think that someone around here has a project which does exactly that actually), but there is no runtime reflection built into D. If you wanted to, you could write code which would produce xml files that held type information which could be read at runtime, but again, since there is no runtime reflection in D, you'd have to do it yourself. Not to mention, reading XML is not exactly very efficient given that you'd be both reading a file and having to deal with parsing text, so I don't know why you'd generally want to use XML to hold type information. XML has its uses, but usually I'd think that you'd want runtime reflection to be efficient, and XML isn't going to do that. - Jonathan M Davis
Oct 24 2010
parent Sclytrack <sclytrack fake.com> writes:
== Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article
 On Sunday 24 October 2010 12:17:47 Sclytrack wrote:
 Instead of targeting doc files, could dmd create xml files
 for the purpose of runtime reflection, instead of trying to
 go to runtime reflection via __traits.

 You can archive these files together with the binary code.
 Create some sort of D package.

 I mean C (GNOME) is going with xml files for their introspection.
 http://library.gnome.org/devel/gi/unstable/gi-gir-reference.html

useful in creating templates and string mixins and the like. If you want runtime reflection, it's possible to use __traits to put together a set of functions which hold the traits information to be queried at runtime, thereby creating your own runtime reflection mechanism (I think that someone around here has a project which does exactly that actually), but there is no runtime reflection built into D. If you wanted to, you could write code which would produce xml files that held type information which could be read at runtime, but again, since there is no runtime reflection in D, you'd have to do it yourself. Not to mention, reading XML is not exactly very efficient given that you'd be both reading a file and having to deal with parsing text, so I don't know why you'd generally want to use XML to hold type information. XML has its uses, but usually I'd think that you'd want runtime reflection to be efficient, and XML isn't going to do that. - Jonathan M Davis

Maybe the xml data could be converted to some faster loadable format by a tool external to the compiler. D---->xml---->runtime reflection library D---->xml---->[binary files---->runtime reflection library] D---->xml---->More D code. C---->xml---->Wrappers in other languages. C---->xml---->D binding code. D------__traits()---->More D Code
Oct 25 2010
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Sclytrack" <sclytrack idiot.com> wrote in message 
news:ia20oq$1rnn$1 digitalmars.com...
 Instead of targeting doc files, could dmd create xml files
 for the purpose of runtime reflection, instead of trying to
 go to runtime reflection via __traits.

 You can archive these files together with the binary code.
 Create some sort of D package.

 I mean C (GNOME) is going with xml files for their introspection.
 http://library.gnome.org/devel/gi/unstable/gi-gir-reference.html

What's the point of inserting a serializing->deserializing step into it?
Oct 24 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, October 25, 2010 11:55:53 Sclytrack wrote:
 == Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article
 
 On Sunday 24 October 2010 12:17:47 Sclytrack wrote:
 Instead of targeting doc files, could dmd create xml files
 for the purpose of runtime reflection, instead of trying to
 go to runtime reflection via __traits.
 
 You can archive these files together with the binary code.
 Create some sort of D package.
 
 I mean C (GNOME) is going with xml files for their introspection.
 http://library.gnome.org/devel/gi/unstable/gi-gir-reference.html

__traits isn't runtime reflection. It's compile time reflection. It's highly useful in creating templates and string mixins and the like. If you want runtime reflection, it's possible to use __traits to put together a set of functions which hold the traits information to be queried at runtime, thereby creating your own runtime reflection mechanism (I think that someone around here has a project which does exactly that actually), but there is no runtime reflection built into D. If you wanted to, you could write code which would produce xml files that held type information which could be read at runtime, but again, since there is no runtime reflection in D, you'd have to do it yourself. Not to mention, reading XML is not exactly very efficient given that you'd be both reading a file and having to deal with parsing text, so I don't know why you'd generally want to use XML to hold type information. XML has its uses, but usually I'd think that you'd want runtime reflection to be efficient, and XML isn't going to do that. - Jonathan M Davis

Maybe the xml data could be converted to some faster loadable format by a tool external to the compiler. D---->xml---->runtime reflection library D---->xml---->[binary files---->runtime reflection library] D---->xml---->More D code. C---->xml---->Wrappers in other languages. C---->xml---->D binding code. D------__traits()---->More D Code

But why would you _want_ the xml? The ideal situation would be something similar to Java where there are functions which you can call at runtime to inquire about an object. D has that for compile time but not runtime. So, you can use the compile time reflection to generate functions which do it at runtime. It's just not built in or standard. But xml? What do you possiblly gain by having xml? It makes no sense to me to try and use runtime reflection for language bindings, and you'd likely use C to interface with other languages if D can't interface with them directly. I just don't see why you would want a runtime reflection mechanism which was language agnostic, and there's no way that it would be an improvement for D to use xml to talk to D. - Jonathan M Davis
Oct 25 2010
prev sibling parent reply Rory McGuire <rjmcguire gmail.com> writes:
To get some basic runtime reflection one could use dmd's json dump.

and then use import("filename.json") to get the json into the 
executable. Then make a class which makes it more usable as a
reflection system.

You can try it out by compiling this code twice, first time with a 
dummy jsontest.json.

=============jsontest.d=========
// compile with: dmd -J./ -X jsontest.d
import std.stdio;

string jsondata = import("jsontest.json");

int getnumber() {
	return 1376;
}

void main() {
	writeln("hello world!", getnumber());
	writeln(jsondata);
}
===================================

works on linux, output is:
hello world!1376
[
{
"kind" : "module",
"file" : "jsontest.d",
"members" : [
{
"name" : "jsondata",
"kind" : "variable",
"type" : "string",
"line" : 3}
,
{
"name" : "getnumber",
"kind" : "function",
"type" : "int()",
"line" : 5}
,
{
"name" : "main",
"kind" : "function",
"type" : "void()",
"line" : 9}
]
}
]



Regards
-Rory


Sclytrack wrote:

 Instead of targeting doc files, could dmd create xml files
 for the purpose of runtime reflection, instead of trying to
 go to runtime reflection via __traits.
 
 You can archive these files together with the binary code.
 Create some sort of D package.
 
 I mean C (GNOME) is going with xml files for their introspection.
 http://library.gnome.org/devel/gi/unstable/gi-gir-reference.html
 
 ---------------------------------------------------------
 dmd is a 42 bit compiler.
 oh W. just added another bit.
 dmd is now a 43 bit compiler.
 ---------------------------------------------------------

Oct 26 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/26/10 10:29 CDT, Rory McGuire wrote:
 To get some basic runtime reflection one could use dmd's json dump.

 and then use import("filename.json") to get the json into the
 executable. Then make a class which makes it more usable as a
 reflection system.

 You can try it out by compiling this code twice, first time with a
 dummy jsontest.json.

That's a very interesting idea. Andrei
Oct 26 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Andrei:

 Rory McGuire:
 To get some basic runtime reflection one could use dmd's json dump.

 and then use import("filename.json") to get the json into the
 executable. Then make a class which makes it more usable as a
 reflection system.

 You can try it out by compiling this code twice, first time with a
 dummy jsontest.json.

That's a very interesting idea.

I have recently suggested a: __traits(json, moduleName) to be used with CTFE that process the resulting JSON tree data (represented with tagged unions, etc). It's a little step forward for static introspection in D. But at best it's not a fast/efficient thing. Bye, bearophile
Oct 26 2010