On 2 April 2012 06:27, Adam D. Ruppe <destructiona...@gmail.com> 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.
Looks good, adds a lot to the compile-time reflection capabilities. My thoughts for it are similar to yours, generating bindings from "export"ed members, so you don't need to maintain separate lists or use a naming convention. -- James Miller