Lack of isPublic isPrivate isProtected compile time reflection features

[Jonathan M Davis]

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