traits getProtection

[James Miller]

On 2 April 2012 06:27, Adam D. Ruppe <destructionator at 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