Ns_enum and Ns_options(nshipster.com)
nshipster.com
Ns_enum and Ns_options
http://nshipster.com/ns_enum-ns_options/
2 comments
I started using NS_ENUM, but I noticed that if I used it in a header file, if I tried to make a property or variable of the enum type: @property (assign) EnumType, it would require this to prefaced with enum, i.e. @property (assign) enum EnumType.
If you just type typedef enum {...} EnumType, you could write @property (assign) EnumType. I prefer this format in my source code, so I quit using NS_ENUM.
If you just type typedef enum {...} EnumType, you could write @property (assign) EnumType. I prefer this format in my source code, so I quit using NS_ENUM.
I'm not seeing the same behavior. Just whipped up a test project and I'm able to define an enum with the macro and import it into a view controller which declares a property of that type.
What your describing would suggest that perhaps you left out the 'typedef' before calling the macro.
What your describing would suggest that perhaps you left out the 'typedef' before calling the macro.
Well, arrays of string constants are categorically the wrong tool for the job if you're talking about the function of a bitmask. You want a set for that, not an array. And it's not a bad idea to go ahead and use a dictionary since you can get the same functionality, and that will let you seamlessly add in non-boolean options down the line.
Except in tightly optimized code, I really think that using bitmasks is an antipattern. It's way harder to inspect a bitmask than a set or dictionary when debugging, and code dealing with them tends to be less readable. In addition, bitmasks sometimes have a tendency to encourage developers to be "clever" and do manipulations with them beyond simple &s and |s. Maintaining such code is, of course, a nightmare.