www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Lack of isPublic isPrivate isProtected compile time reflection

reply 12345swordy <alexanderheistermann gmail.com> writes:
I don't see it anywhere in the std.traits library nor in the 
default compiler traits. This shouldn't be difficult to 
implemented them in the std.traits library isn't it?

-Alexander
Jul 08 2018
parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 8 July 2018 at 20:58:54 UTC, 12345swordy wrote:

 I don't see it anywhere in the std.traits library nor in the 
 default compiler traits. This shouldn't be difficult to 
 implemented them in the std.traits library isn't it?

 -Alexander


hello, look at
__traits(getProtection)[1] in the language traits

[1] https://dlang.org/spec/traits.html#getProtection
Jul 08 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Sunday, 8 July 2018 at 21:20:27 UTC, Basile B. wrote:

 On Sunday, 8 July 2018 at 20:58:54 UTC, 12345swordy wrote:

 I don't see it anywhere in the std.traits library nor in the 
 default compiler traits. This shouldn't be difficult to 
 implemented them in the std.traits library isn't it?

 -Alexander


 hello, look at
 __traits(getProtection)[1] in the language traits

 [1] https://dlang.org/spec/traits.html#getProtection


Oh, thank you!

-Alexander
Jul 08 2018
parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 8 July 2018 at 21:26:14 UTC, 12345swordy wrote:

 On Sunday, 8 July 2018 at 21:20:27 UTC, Basile B. wrote:

 On Sunday, 8 July 2018 at 20:58:54 UTC, 12345swordy wrote:

 I don't see it anywhere in the std.traits library nor in the 
 default compiler traits. This shouldn't be difficult to 
 implemented them in the std.traits library isn't it?

 -Alexander


 hello, look at
 __traits(getProtection)[1] in the language traits

 [1] https://dlang.org/spec/traits.html#getProtection


 Oh, thank you!

 -Alexander


By the way i forgot to mention something : it would not 
necessarily be a good idea to put wrappers named isPrivate(), 
isPublic(), etc. in std.traits because if the wrappers are 
instantiated in std.traits they could not work correctly because 
the symbol that they would inspect would not be accessible (since 
located elsewhere)... I'm not 100% sure if 
__traits(getProtection) is affected but the problem described is 
known as a problem when doing introspection with getMember for 
example.
Jul 09 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 07/09/2018 05:24 AM, Basile B. wrote:

 
 By the way i forgot to mention something : it would not necessarily be a 
 good idea to put wrappers named isPrivate(), isPublic(), etc. in 
 std.traits because if the wrappers are instantiated in std.traits they 
 could not work correctly because the symbol that they would inspect 
 would not be accessible (since located elsewhere)... I'm not 100% sure 
 if __traits(getProtection) is affected but the problem described is 
 known as a problem when doing introspection with getMember for example.


Isn't it pretty much standard in most languages for reflection to bypass 

it's been a long time.
Jul 09 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, 9 July 2018 14:30:00 MDT Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:

 On 07/09/2018 05:24 AM, Basile B. wrote:

 By the way i forgot to mention something : it would not necessarily be a
 good idea to put wrappers named isPrivate(), isPublic(), etc. in
 std.traits because if the wrappers are instantiated in std.traits they
 could not work correctly because the symbol that they would inspect
 would not be accessible (since located elsewhere)... I'm not 100% sure
 if __traits(getProtection) is affected but the problem described is
 known as a problem when doing introspection with getMember for example.


 Isn't it pretty much standard in most languages for reflection to bypass

 it's been a long time.


D currently does not. As I understand it, after the access level stuff was
last reworked so that private stuff didn't affect function overloading, it
was decided that we needed to change it so that it did allow code
introspection to examine private symbols (not necessarily to call anything -
I'm not sure that that was decided one way or the other), but AFAIK, no work
has actually been done towards fixing it. However, given that Andrei has
been working on a way to provide type information as a set of structs in
order to simplify and standardize accessing it, I expect that fixes for a
number of issues related to type introspection will finally end up getting
done, because his stuff won't work otherwise.

- Jonathan M Davis
Jul 09 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 9 July 2018 at 21:25:03 UTC, Jonathan M Davis wrote:

 On Monday, 9 July 2018 14:30:00 MDT Nick Sabalausky (Abscissa) 
 via Digitalmars-d wrote:

 On 07/09/2018 05:24 AM, Basile B. wrote:

 [...]


 Isn't it pretty much standard in most languages for reflection 

 that way, but then, it's been a long time.


 D currently does not. As I understand it, after the access 
 level stuff was last reworked so that private stuff didn't 
 affect function overloading, it was decided that we needed to 
 change it so that it did allow code introspection to examine 
 private symbols (not necessarily to call anything - I'm not 
 sure that that was decided one way or the other), but AFAIK, no 
 work has actually been done towards fixing it. However, given 
 that Andrei has been working on a way to provide type 
 information as a set of structs in order to simplify and 
 standardize accessing it, I expect that fixes for a number of 
 issues related to type introspection will finally end up 
 getting done, because his stuff won't work otherwise.

 - Jonathan M Davis


Why as a set of structs? Is this set of structs generated at 
compile time or at runtime? Preferably I want them both compile 
time and runtime reflection. (Yes I know there is a library 
regarding runtime reflection, but you have to modfy your classes 
in order to achieve this functionality)

-Alexander
Jul 09 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, 9 July 2018 18:07:29 MDT 12345swordy via Digitalmars-d wrote:

 On Monday, 9 July 2018 at 21:25:03 UTC, Jonathan M Davis wrote:

 On Monday, 9 July 2018 14:30:00 MDT Nick Sabalausky (Abscissa)

 via Digitalmars-d wrote:

 On 07/09/2018 05:24 AM, Basile B. wrote:

 [...]


 Isn't it pretty much standard in most languages for reflection

 that way, but then, it's been a long time.


 D currently does not. As I understand it, after the access
 level stuff was last reworked so that private stuff didn't
 affect function overloading, it was decided that we needed to
 change it so that it did allow code introspection to examine
 private symbols (not necessarily to call anything - I'm not
 sure that that was decided one way or the other), but AFAIK, no
 work has actually been done towards fixing it. However, given
 that Andrei has been working on a way to provide type
 information as a set of structs in order to simplify and
 standardize accessing it, I expect that fixes for a number of
 issues related to type introspection will finally end up
 getting done, because his stuff won't work otherwise.

 - Jonathan M Davis


 Why as a set of structs? Is this set of structs generated at
 compile time or at runtime? Preferably I want them both compile
 time and runtime reflection. (Yes I know there is a library
 regarding runtime reflection, but you have to modfy your classes
 in order to achieve this functionality)


It's primarily compile-time but done with the idea that runtime stuff could
be built on top of it.

Andrei isn't so much looking to add more capabilities to what we can do so
much as make compile-time introspection more user-friendly and better
structured. While you can currently get at all kinds of great introspection
information at compile-time, you have to use a bunch of different traits
from both __traits and std.traits, and you often have to combine them in
non-obvious ways to get what you want. So, he wants to present the type
information as a structs at compile time. That way, you can get the struct
representing a type and ask it about each function, variable, etc. that the
type has by getting the information from that struct instead of reaching for
traits from all over the place. It's still going to use those traits
internally, but it's presenting a more user-friendly interface to get at
them. I expect that as this gets implemented, various pain points in
compile-time introspection will be fixed (e.g. access level issues and
issues related to intrsopecting on templates), but really, this is just a
wrapper around the building blocks that we already have.

As for what that means for runtime reflection, it follows the same philosphy
that Andrei has had on this all along in that if you have solid compile-time
introspection, then you can build runtime reflection tools out of it. As the
structs contain data such as strings, they could easily be kept around at
runtime, though something will need to be built on top of that in order to
do much useful at runtime, and it's not at all clear where that's going.
Andrei has clearly thought about it, and it may be that some runtime
reflection capabilities will end up in Phobos alongside the compile-time
stuff, but the focus is on building the compile-time capabilities into
something clean and easy to use, whereas right now, we have something very
powerful but somewhat clunky to use. Once the new compile-time wrappers are
in place, then the question of what can and should be done to better enable
runtime reflection using those tools can be fully explored, but the structs
are being designed so that the information can be made available at runtime.

I suggest that you watch Andrei's dconf talk:

http://dconf.org/2018/talks/alexandrescu.html

It covers this topic at around 40 minutes in, though obviously, I'd suggest
watching the whole thing. He covers several other potentially controversial
changes prior to discussing anything about introspection.

- Jonathan M Davis
Jul 09 2018