<div class="gmail_quote">On 1 April 2012 21:27, Adam D. Ruppe <span dir="ltr"><<a href="mailto:destructionator@gmail.com">destructionator@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've prepared a dmd pull request to add a new __trait:<br>
getProtection.<br>
<br>
It is meant to be used along with getMember() to add to<br>
the reflection capabilities, letting us use the existing<br>
protection qualifiers as strings.<br>
<br>
>From the test:<br>
==<br>
class Test {<br>
    public int a;<br>
    private int b;<br>
    export string c;<br>
    protected int d;<br>
    package void e() {}<br>
}<br>
<br>
void main() {<br>
    Test t;<br>
    static assert(__traits(getProtection, __traits(getMember, t, "a")) == "public");<br>
    static assert(__traits(getProtection, __traits(getMember, t, "b")) == "private");<br>
    static assert(__traits(getProtection, __traits(getMember, t, "c")) == "export");<br>
    static assert(__traits(getProtection, __traits(getMember, t, "d")) == "protected");<br>
    static assert(__traits(getProtection, __traits(getMember, t, "e")) == "package");<br>
}<br>
==<br>
<br>
<br>
<br>
This will help D automatically generate things like<br>
external interfaces that use the protections.<br>
<br>
For instance, I plan to use it in my web.d to only<br>
make functions marked "export" available via the<br>
web interface. Currently, you have to use a naming<br>
convention to hide functions - a leading underscore -<br>
even on private members. This is ok, but not great.<br>
<br>
But with the protection trait, we can mark it with<br>
a much more natural "private", or any of the other<br>
specifiers D has.<br>
<br>
<br>
I'm sure other uses will come up too.<br></blockquote><div><br></div><div>Wow, it so happens I need to use this immediately (tomorrow), and I assumed it was already possible...</div><div>I wonder about the protection flags used this way though.</div>
<div>I want to generate external interfaces for all public stuff, but it occurred to me that an explicit modifier like export would be more appropriate to control what is exposed.</div><div>The problem with 'export' is it's already defined to export from a shared object/dll, and my code IS a dll, so export is not something I can overload for this purpose...</div>
<div>export(dll) maybe? Then you could describe other export types... ?</div><div><br></div><div>... this is another perfect use for... custom attributes! ;)</div><div>I also need to tag functions/classes/methods/properties as being saved, state recorded, editor exposed, script bound... I have a bucket load of needs for custom attributes.</div>
</div>