Member access control

Oct 15, 2007 at 6:09 PM
Nice job getting member access control in place. A couple thoughts that crosssed my mind as I was exploiting the feature in my project:
  • Instead of the two boolean properties on ExpressionOptions, did you consider a single property of type System.Reflection.BindingFlags? Not every BindingFlags value is relevant to Flee, but the semantics of those that are match the intent of member access control well enough. Should you get (even more) ambitious and decide to allow, say, static vs. instance member filtering, your interface wouldn't change a bit. Your documentation could simply state which flags Flee recognizes, and just ignore the rest.
  • <nit>The two new ExpressionOptions properties default to true. Even though it might break existing deployments of Flee, I'd vote for disallowing non-public members by default. In any case, documenting the defaults wouldn't be a bad idea.</nit>
Oct 15, 2007 at 8:01 PM
Yeah, I didn't like the two property approach either, but I wanted to put something in and refine it later. I like the BindingFlags approach better as it is more flexible and compact.

I agree that only allowing public members should be the default. Most people use the DynamicExpressionOwner, so the decision won't even affect them and, in the end, it will prevent a lot of problems.
Nov 6, 2007 at 2:10 AM
I've implemented the OwnerMemberAccess property using BindingFlags and set the default to Public
in Flee-