Re: enum scope

[deadalnix via Digitalmars-d]

On Thursday, 26 January 2012 at 11:55:00 UTC, Michel Fortin wrote:
On 2012-01-26 01:12:40 +0000, Jonathan M Davis 
<jmdavisp...@gmx.com> said:

On Thursday, January 26, 2012 02:06:45 Trass3r wrote:
When writing C bindings I usually create lots of aliases via a
string mixin to pull enum members into the enclosing scope so
it's compatible to C.
Would it be wise to let the compiler do this automatically for
extern(C) enums?

Why? You're using them in D code, not C code. What difference 
does it make if
the enum is one that's used in C code or not? Why would you 
use such aliases
with enums from C but not those from D/ What makes enums from 
C different?

Often C enum value naming takes into account that they'll live 
in the outer scope. For instance:

        enum UITableViewRowAnimation {
        UITableViewRowAnimationFade,
            UITableViewRowAnimationRight,
            UITableViewRowAnimationLeft,
            UITableViewRowAnimationTop,
            UITableViewRowAnimationBottom,
            UITableViewRowAnimationNone,
            UITableViewRowAnimationMiddle,
            UITableViewRowAnimationAutomatic = 100
        }

So if you're doing direct bindings where you don't want to 
change the names, how do you use that in D?

        UITableViewRowAnimation.UITableViewRowAnimationFade

I'm not sure why it is usually done that way in D binding. This 
is idiotic (and all Deimos exhibit this).

enum UITableViewRowAnimation {
    Fade,
    Right,
    Left,
    Top,
    Bottom,
    None,
    Middle,
    Automatic = 100
}

Here you go. You gain type safety (well kind of) and you don't 
need to increase verbosity. You can even use the with statement 
for code that use the enum intensively, for instance :

final switch(myvar) with(UITableViewRowAnimation) {
    case Fade:
       // Do fading...
    case Right:
       // That's right...
    case Left:
       // That's not right..
    // And so on...
}

That is superior to the idiotic C copy pasta in all aspects.