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 reply 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


 __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
Oct 25 2010
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 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 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