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

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

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

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.

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 access privileges? I seem to remember Java/C# being that way, but then, it's been a long time.

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 access privileges? I seem to remember Java/C# being 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

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 to bypass access privileges? I seem to remember Java/C# being 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

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 to bypass access privileges? I seem to remember Java/C# being 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