On 01.04.2012 22:27, Adam D. Ruppe wrote:
I've prepared a dmd pull request to add a new __trait: getProtection.It is meant to be used along with getMember() to add to the reflection capabilities, letting us use the existing protection qualifiers as strings. From the test: == class Test { public int a; private int b; export string c; protected int d; package void e() {} } void main() { Test t; static assert(__traits(getProtection, __traits(getMember, t, "a")) == "public"); static assert(__traits(getProtection, __traits(getMember, t, "b")) == "private"); static assert(__traits(getProtection, __traits(getMember, t, "c")) == "export"); static assert(__traits(getProtection, __traits(getMember, t, "d")) == "protected"); static assert(__traits(getProtection, __traits(getMember, t, "e")) == "package"); } == This will help D automatically generate things like external interfaces that use the protections. For instance, I plan to use it in my web.d to only make functions marked "export" available via the web interface. Currently, you have to use a naming convention to hide functions - a leading underscore - even on private members. This is ok, but not great. But with the protection trait, we can mark it with a much more natural "private", or any of the other specifiers D has. I'm sure other uses will come up too.
It's all nice and well, but I believe part of the reason of say private protection is that user is never ever able to see(!) it. Thus it user can't depend on private members being there, which is a good thing. If I read it right, the technique you present allows user code to depend on private functions being there. I argue that we shouldn't even provide a _possibility_ for external stuff to depend on private members.
Same argument in limited scope goes for protected. As for export, I thinks it looks OK. -- Dmitry Olshansky
