Thread overview | ||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
March 30, 2015 std.reflection prototype | ||||
---|---|---|---|---|
| ||||
I came across this post a while back and decided to implement it: http://forum.dlang.org/thread/juf7sk$16rl$1@digitalmars.com My implementation: https://github.com/bitwise-github/D-Reflection The above conversation seemed to stop abruptly, so I went on to assume that no one chose to champion the task. At the time, I looked around for other conversations or attempts at runtime reflection for D, but couldn't really find anything. I did find the ModuleInfo/reflection stuff in object.d, but it seemed like an effort that may have been abandoned. Also, the above conversation seemed to suggest it should be opt-in, which also made me wonder if the stuff in object.d was abandoned or for a different purpose. Looking again today, someone seems to have been working on it a bit.. For example, MemberInfo_field and MemberInfo_function were empty last time I checked. So what's the current state of things? Is anybody working on it? Although MemberInfo_field exists, it doesn't seem to be available from TypeInfo_Class... Is that the eventual goal? Is there anything I can do to help get things moving? Any comments on my implementation would be welcome as well. (https://github.com/bitwise-github/D-Reflection) main.d shows some general use cases, but basically, if the reflect(T) template is used on a class, that class, and any child types will be reflected. Recursive reflection only propagates downward, or else it could leak sideways and unnecessarily reflect several modules. Most of the reflection information is available at compile time. For example: enum name = reflectModule!(test).findClass("Test").findField("variable").name; pragma(msg, name); // "variable" will be outputted. To make a module available for runtime reflection, the following can be used: mixin(runtimeReflection!test); At this point, the above example can be rewritten as: string name = getModuleReflection("tests.test").findClass("Test3").findField("static_variable").name; writeln(name); |
March 30, 2015 Re: std.reflection prototype | ||||
---|---|---|---|---|
| ||||
Posted in reply to bitwise | On 30/03/2015 2:11 p.m., bitwise wrote:
> I came across this post a while back and decided to implement it:
> http://forum.dlang.org/thread/juf7sk$16rl$1@digitalmars.com
>
> My implementation:
> https://github.com/bitwise-github/D-Reflection
>
> The above conversation seemed to stop abruptly, so I went on to assume
> that no one chose to champion the task.
>
> At the time, I looked around for other conversations or attempts at
> runtime reflection for D, but couldn't really find anything. I did find
> the ModuleInfo/reflection stuff in object.d, but it seemed like an
> effort that may have been abandoned. Also, the above conversation seemed
> to suggest it should be opt-in, which also made me wonder if the stuff
> in object.d was abandoned or for a different purpose.
>
> Looking again today, someone seems to have been working on it a bit..
> For example, MemberInfo_field and MemberInfo_function were empty last
> time I checked.
>
> So what's the current state of things?
> Is anybody working on it?
>
> Although MemberInfo_field exists, it doesn't seem to be available from
> TypeInfo_Class... Is that the eventual goal?
>
> Is there anything I can do to help get things moving?
>
>
> Any comments on my implementation would be welcome as well.
> (https://github.com/bitwise-github/D-Reflection)
>
> main.d shows some general use cases, but basically, if the reflect(T)
> template is used on a class,
> that class, and any child types will be reflected. Recursive reflection
> only propagates downward, or else it could leak sideways and
> unnecessarily reflect several modules.
>
> Most of the reflection information is available at compile time. For
> example:
>
> enum name =
> reflectModule!(test).findClass("Test").findField("variable").name;
> pragma(msg, name); // "variable" will be outputted.
>
> To make a module available for runtime reflection, the following can be
> used:
> mixin(runtimeReflection!test);
>
> At this point, the above example can be rewritten as:
>
> string name =
> getModuleReflection("tests.test").findClass("Test3").findField("static_variable").name;
>
> writeln(name);
I love the idea of it.
But first we need to finish off what support we damn well have in druntime.
m_offTi for TypeInfo_Class currently is not being generated.
We also need some form of RTInfo for modules. Not just for symbols. This alone will open up quite a few doors!
|
March 30, 2015 Re: std.reflection prototype | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rikki Cattermole | > But first we need to finish off what support we damn well have in druntime.
>
> m_offTi for TypeInfo_Class currently is not being generated.
>
> We also need some form of RTInfo for modules. Not just for symbols. This alone will open up quite a few doors!
In the "time for std.reflection" convo, it seemed like Andre was talking about a library solution, and not something compiler generated.. has that idea since been thrown out?
Has there been other conversations on this that I missed?
Thanks
|
March 30, 2015 Re: std.reflection prototype | ||||
---|---|---|---|---|
| ||||
Posted in reply to bitwise | On 30/03/2015 5:39 p.m., bitwise wrote: >> But first we need to finish off what support we damn well have in >> druntime. >> >> m_offTi for TypeInfo_Class currently is not being generated. >> >> We also need some form of RTInfo for modules. Not just for symbols. >> This alone will open up quite a few doors! > > In the "time for std.reflection" convo, it seemed like Andre was talking > about a library solution, and not something compiler generated.. has > that idea since been thrown out? This definitely should be a library solution. But it seems silly, to not use code in druntime. Either that, or if it is like m_offTi, remove it. After all, it was never implemented. > Has there been other conversations on this that I missed? No. |
March 30, 2015 Re: std.reflection prototype | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rikki Cattermole | > This definitely should be a library solution. In terms of what Andre was suggesting, I think my implementation is 90% of the way there, so if the will was there to add something like std.reflection to phobos, it wouldn't be much of a leap. > But it seems silly, to not use code in druntime. I kind of agree. If I had things my way, all reflection info for all classes would be compiler generated so that it was guaranteed to be there for tools, interop and such. If people were really worried about code bloat, the reflection info could simply be turned off with a -no-reflection flag or something. In terms of playing around with the compiler and the type system, I'm not sure how helpful I could be right now. I'm pretty sure comprehension will not be a problem, but I've got quite a bit of reading to do before I'm up to speed with whats going on with dmd and the type system. |
March 30, 2015 Re: std.reflection prototype | ||||
---|---|---|---|---|
| ||||
Posted in reply to bitwise | On 30/03/2015 6:06 p.m., bitwise wrote: >> This definitely should be a library solution. > > In terms of what Andre was suggesting, I think my implementation is 90% > of the way there, so if the will was there to add something like > std.reflection to phobos, it wouldn't be much of a leap. > >> But it seems silly, to not use code in druntime. > > I kind of agree. If I had things my way, all reflection info for all > classes would be compiler generated so that it was guaranteed to be > there for tools, interop and such. If people were really worried about > code bloat, the reflection info could simply be turned off with a > -no-reflection flag or something. > > In terms of playing around with the compiler and the type system, I'm > not sure how helpful I could be right now. I'm pretty sure comprehension > will not be a problem, but I've got quite a bit of reading to do before > I'm up to speed with whats going on with dmd and the type system. I have so many views upon all this, thanks to my new (not released as not ready) web service framework. But druntime right now is not ready for proper reflection. There needs to be some modifications to it and dmd. But mostly druntime for RTInfo. For example what shouldn't needed to be done. Here is my install information for my autoconfig system. (Allows for publically importing any module I want AND handling any symbol that the system has used. #Install ## Configure per type RTInfo requires a single modification. [Based upon a forum thread](http://forum.dlang.org/post/majnjuhxdefjuqjlpbmv@forum.dlang.org). ```D template RTInfo(T, string moduleName = __MODULE__) { enum RTInfo = cast(void*)0x12345678; static if (__traits(compiles, {import core.config;})) { import core.config; alias checkResult = TypeCheck!(T, moduleName); } } ``` ## Auto imports COPY/core/configimports.d needs to be copied to import/core/configimports.d Also needed is object.di under imports to be modified. Add ``D public import core.configimports;`` anywhere you want. |
March 30, 2015 Re: std.reflection prototype | ||||
---|---|---|---|---|
| ||||
Posted in reply to bitwise | On Monday, 30 March 2015 at 05:06:14 UTC, bitwise wrote: >> This definitely should be a library solution. > > In terms of what Andre was suggesting, I think my implementation is 90% of the way there, so if the will was there to add something like std.reflection to phobos, it wouldn't be much of a leap. > >> But it seems silly, to not use code in druntime. > > I kind of agree. If I had things my way, all reflection info for all classes would be compiler generated so that it was guaranteed to be there for tools, interop and such. If people were really worried about code bloat, the reflection info could simply be turned off with a -no-reflection flag or something. > > In terms of playing around with the compiler and the type system, I'm not sure how helpful I could be right now. I'm pretty sure comprehension will not be a problem, but I've got quite a bit of reading to do before I'm up to speed with whats going on with dmd and the type system. When I tried mine (https://shardsoft.com/stash/projects/SHARD/repos/shardtools/browse/source/ShardTools/Reflection.d), which was admittedly a while back, the template bloat was actually a significant problem. On Linux and OSX, the build for just the unittest library would generate an over 40MB executable. On Windows with Optlink though, it was only 4MB, so perhaps there are optimizations that could be made to reduce the size on OSX / Linux. Either way though, that's way too much bloat for something in druntime, and I don't think it's necessary. While it might be nice to use RTInfo to generate reflection data for your whole program, most people would be perfectly okay with at most a few modules, possibly recursively. Also, from what I can tell you generate a class for every symbol. This could generate a significant amount of bloat as well because it would generate further TypeInfo for each of these classes. I could be wrong here, but if that's the case, perhaps changing to structs would be a better choice if possible? |
March 30, 2015 Re: std.reflection prototype | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rikki Cattermole | On 2015-03-30 04:09, Rikki Cattermole wrote: > We also need some form of RTInfo for modules. I made a pull request for that but unfortunately it hasn't been accepted yet. The reason seems to be that we need to come up with a way to do custom RTInfo without modifying druntime, that can also be used for this template. -- /Jacob Carlborg |
March 30, 2015 Re: std.reflection prototype | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On 30/03/2015 7:59 p.m., Jacob Carlborg wrote:
> On 2015-03-30 04:09, Rikki Cattermole wrote:
>
>> We also need some form of RTInfo for modules.
>
> I made a pull request for that but unfortunately it hasn't been accepted
> yet. The reason seems to be that we need to come up with a way to do
> custom RTInfo without modifying druntime, that can also be used for this
> template.
You, me and Walter should have a chat then. I could pretty easily come up with a way to add data into RTInfo.
|
March 30, 2015 Re: std.reflection prototype | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rikki Cattermole | On 2015-03-30 09:06, Rikki Cattermole wrote: > You, me and Walter should have a chat then. I could pretty easily come > up with a way to add data into RTInfo. I've already come up with a way, any template with the @rtInfo UDA is treated the same way as RTInfo is now. The problem is then how to store the data in TypeInfo. Since it would be possible to have multiple data generated for a given type I was thinking it could be stored in an associative array. The keys would be the name of the module which generated the data and the the values would be the data. Something like this: module foo.bar; @rtInfo template Foo (T) { enum Foo = "bar"; } assert(typeid(T).rtInfo["foo.bar"] == "bar"); If I recall correctly Martin Nowak didn't like this approach. The associate array would need to be built at load time of the application due to separate compilation. BTW, here [1] is the pull request and the reason why it was closed. [1] https://github.com/D-Programming-Language/dmd/pull/2271#issuecomment-59621060 -- /Jacob Carlborg |
Copyright © 1999-2021 by the D Language Foundation