The SLAR (vol2) on System.Reflection.BindingFlags


Continuing in the series sharing some of the information in the .NET Framework Standard Library Annotated Reference Vol 1 and .NET Framework Standard Library Annotated Reference Vol 2 with some information on BindingFlags.


 


public enum BindingFlags


{


CreateInstance = 0x200,


DeclaredOnly = 0x2,


MS Default = 0x0,


ExactBinding = 0x10000,


MS FlattenHierarchy = 0x40,


GetField = 0x400,


GetProperty = 0x1000,


IgnoreCase = 0x1,


MS IgnoreReturn = 0x1000000,


Instance = 0x4,


InvokeMethod = 0x100,


NonPublic = 0x20,


OptionalParamBinding = 0x40000,


Public = 0x10,


MS PutDispProperty = 0x4000,


MS PutRefDispProperty = 0x8000,


SetField = 0x800,


SetProperty = 0x2000,


Static = 0x8,


SuppressChangeType = 0x20000,


}


 


 


KC


When we teach API design, we often use this enum as an example of a bad enum design. The


problem is that this enum is actually combining several different concepts: visibility selection,


member selection, binding algorithm, and so on, yet it claims to be Flags enum, which would


imply the values can be used independently or together, using the binary OR operator. This is


not the case. Just look at the documentation for this enum. It spells out several rules for the


usage of the enum. It’s probably the most complicated enum documentation in the whole


framework.


 


BG


This enum has two different axes, and both must be specified when using the enum. The first is


the type of method—static or instance. The second is visibility—public or non–public. You must


specify one or both of those values when using the BindingFlags enum, and it’s remarkably


easy to forget to specify one of these. It’s a surprisingly common problem for users of


Reflection. I certainly wish we would have done something a little more explicit here.



 


JP


A funny thing about the BindingFlags enum: we originally had a lot more binding flag


options (aren’t there already enough?!), which we ripped out just before RTM ship. These


included things like predefined BindingFlags combinations (BindingFlags.Private, etc.)


and more granular binding flags.


 


JP


BindingFlags.IgnoreCase has some performance and working set implications associated


with it (we double the Reflection string cache and lowercase all strings passed in). If your


scenario doesn’t need it, try to avoid it.

Comments (0)