On Sunday, 7 April 2019 at 17:42:58 UTC, Alex wrote:
That is blatantly wrong. The code works EXACTLY the same way
with and without using stringof.
In some cases, yeah. In the general case, no.
Your import hack* is only there because of stringof. Using the
local symbol, there is no need to import the module. This means
you avoid name conflicts with local symbols (like I pointed out
in the linked post) and it has the potential to avoid protection
violation errors, since you are no longer getting the symbol from
your module; it is gotten somewhere else, ideally from its own
module, and passed to you, which is allowed even for private or
hidden symbols.
It also just makes the code a lot simpler, so there's no more
need to jump through hoops to debug it.
*
https://github.com/IncipientDesigns/Dlang_Reflect/blob/master/mReflect.d#L61
I have removed all T.stringof's in the code and I still get the
exact same errors.
That's the first step. Then, you clean up the hacks that were
introduced to work around stringof's problems and get a better
design that actually works, like passing private members from one
module to another via alias parameters.
one could just open the source if there was anything to "hide"
That's not necessarily true, it is possible to have code exclude
private members. In fact, it is often considered good practice to
do that for library releases for encapsulation!
Protection is a runtime thing(except for CTFE).
Protection *only* exists at compile time - at runtime, there's
zero checks. There's nothing preventing you from passing a
pointer to a private member, for example.
This is why __traits(getMember) fails the same as T.name, but it
is also the reason why there's hope to cheat here, at least once
you get a correct foundation laid, by using mixin templates
and/or passing aliases cross module.
(interestingly, .tupleof does let you bypass privacy protections,
but only for aggregate members, not for methods.)
