Fix issue 4813 trait for getting at access modifiers #952

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
6 participants
@jmaschme

Added isPublic, isPrivate, isProtected, isPackage, and isExport traits

Fix issue 4813
Added isPublic, isPrivate, isProtected, isPackage, and isExport traits
@jmaschme

This comment has been minimized.

Show comment Hide comment
@mrmonday

This comment has been minimized.

Show comment Hide comment
@mrmonday

mrmonday May 16, 2012

Contributor

Would a getProtection trait not be more useful/flexible? Otherwise we'll end up with lots of wrappers for it unless they're added to phobos.

Contributor

mrmonday commented May 16, 2012

Would a getProtection trait not be more useful/flexible? Otherwise we'll end up with lots of wrappers for it unless they're added to phobos.

@jmaschme

This comment has been minimized.

Show comment Hide comment
@jmaschme

jmaschme May 16, 2012

I think that would probably be best left for Phobos. There is no built-in representation for a protection type, so what would a getProtection trait return.

Also this approach is fairly consistent with the existing traits (isStaticFunction, isFinalFunction, isVirtualFunction, etc).

I think that would probably be best left for Phobos. There is no built-in representation for a protection type, so what would a getProtection trait return.

Also this approach is fairly consistent with the existing traits (isStaticFunction, isFinalFunction, isVirtualFunction, etc).

@mrmonday

This comment has been minimized.

Show comment Hide comment
@mrmonday

mrmonday May 17, 2012

Contributor

I was thinking a string. It's fine either way I guess as long as the inverse is in phobos (with the current pull I'd expect a getProtection template in phobos which returns a string with the protection type).

Contributor

mrmonday commented May 17, 2012

I was thinking a string. It's fine either way I guess as long as the inverse is in phobos (with the current pull I'd expect a getProtection template in phobos which returns a string with the protection type).

@alexrp

This comment has been minimized.

Show comment Hide comment
@alexrp

alexrp Jul 5, 2012

Member

Given that we have isVirtualFunction, isFinalFunction, and so on, I'd go for consistency and do it like this pull request does. It would have been better to have traits that returned strings for these things, but now we're stuck with the other approach, so let's be consistent.

Member

alexrp commented Jul 5, 2012

Given that we have isVirtualFunction, isFinalFunction, and so on, I'd go for consistency and do it like this pull request does. It would have been better to have traits that returned strings for these things, but now we're stuck with the other approach, so let's be consistent.

@andralex

This comment has been minimized.

Show comment Hide comment
@andralex

andralex Sep 25, 2012

Member

I just reviewed a pull request that added protection level detection to __traits: D-Programming-Language#856. How do these two compare?

Member

andralex commented Sep 25, 2012

I just reviewed a pull request that added protection level detection to __traits: D-Programming-Language#856. How do these two compare?

@adamdruppe

This comment has been minimized.

Show comment Hide comment
@adamdruppe

adamdruppe Sep 26, 2012

Contributor

I just tried using this DSYMBOL macro on my code, and it didn't pass an important test to me: it didn't give the protection on members returned from traits(getMember).

Contributor

adamdruppe commented Sep 26, 2012

I just tried using this DSYMBOL macro on my code, and it didn't pass an important test to me: it didn't give the protection on members returned from traits(getMember).

@adamdruppe

This comment has been minimized.

Show comment Hide comment
@adamdruppe

adamdruppe Sep 26, 2012

Contributor

I pushed an update to mine that passes the tests I need - in addition to the macro, gotta check for various dot expressions. Take a look at the pull request Andrei linked to.

Other than that, the difference is I return a string instead of doing is... meh either way works for me, the string just seemed simpler.

Contributor

adamdruppe commented Sep 26, 2012

I pushed an update to mine that passes the tests I need - in addition to the macro, gotta check for various dot expressions. Take a look at the pull request Andrei linked to.

Other than that, the difference is I return a string instead of doing is... meh either way works for me, the string just seemed simpler.

@9rnsr 9rnsr referenced this pull request Sep 29, 2012

Merged

Protection trait #856

@WalterBright

This comment has been minimized.

Show comment Hide comment
@WalterBright

WalterBright Nov 11, 2012

Member

Closed as it is redundant with #856.

Member

WalterBright commented Nov 11, 2012

Closed as it is redundant with #856.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment