This project has moved. For the latest updates, please go here.

Test if member exists

Feb 2, 2010 at 3:34 PM
Edited Feb 3, 2010 at 1:09 PM

Hi Fasterflect Team,

first I'd like to say that your lib is really great.

 

I have a use case where I iterate over several types and need to test if a member exists before I call GetProperty<T> to avoid a MissingMemberException. At the moment I test it with the standard method:

if (type.GetProperty(propName) != null)

But it doesn't use the same BindingFlags as Fasterflect in its GetProperty<T>(propName) so I might miss some types here.
It would be good to have an extension method like "bool : HasMember(propName)" or that null is returned when the member wasn't found instead of throwing a MissingMemberException. This is the behavior most devs know from the .Net FW built-in methods like GetProperty(). Exceptions also kill the performance and debugging sucks when approx. 30 exceptions are raised and each time VS stops there.

Coordinator
Feb 3, 2010 at 7:11 AM

We are glad you like the library.

The latest version of Fasterflect only replaces invocation scenarios of .NET Reflection, not lookup scenarios.  We're implementing the lookup scenarios and they should be available in the next release of Fasterflect.  We definitely implement feature to support your described scenario, which makes a lot of sense to us.  A tracking ticket for this is created here: http://fasterflect.codeplex.com/WorkItem/View.aspx?WorkItemId=5325 - we'll also update this discussion thread when we commit code implementing this feature. 

Feb 3, 2010 at 7:15 AM

That's great. Thanks for your effort!

Feb 18, 2010 at 12:19 PM

I've read in the Issue http://fasterflect.codeplex.com/WorkItem/View.aspx?WorkItemId=5325 that it was implemented and is closed. But I can't find anything in the latest source code. Am I wrong? And if so when is it planned to be implemented.

Coordinator
Feb 19, 2010 at 5:23 AM
Edited Feb 19, 2010 at 5:25 AM

The lookup methods are named Field/Fields, Property/Properties, etc. and return null if no match is found (or an empty list for those that look for multiple members). The lookups should use the same BindingFlags as the access methods for get/set/invoke (which by default would be public and non-public instance members, including those from base classes, but there are overloads where you can specify your own BindingFlags).

You should therefore be able to write code like this:

var prop = type.Property( "Name" );
if( prop != null ) { ... }

Note that there are additional Fasterflect-specific flags available, which provide some additional filtering options (the sample below searches by partial name instead of for an exact match):

Flags flags = Flags.InstanceCriteria | Flags.PartialName;
var props = type.Properties( "Get", flags );
if( props.Count > 0 ) { ... }

Hope this helps!

Feb 19, 2010 at 12:43 PM
Edited Feb 19, 2010 at 12:52 PM

Thanks for the infos. The problem is I gotta check before and the code bloats quickly. What I really need are methods like: TryGetPropertyValue("name", out val) or even better GetPropertyValueSafe("name") which returns null. But why don't you just return null if the value doesn't exist? A MissingMemberException has not much more infos for the caller. I know what type and member name I want to retrieve. This would be better for most practical scenarios and the API stays small.

BTW, what happend to the nice generic overloads like GetProperty<...> ?

Coordinator
Feb 19, 2010 at 3:01 PM
Edited Feb 19, 2010 at 3:01 PM

The reason for this is that it seemed reasonable to first add all the lookup methods, and work to ensure they operate correctly and provide good coverage for common lookup scenarios. Although this work is now considered complete we still need to add the combined lookup/access methods that you desire - there is an open issue for this in the tracker: http://fasterflect.codeplex.com/WorkItem/View.aspx?WorkItemId=5357

I'm currently working on another bit, but will give this a look as soon as I'm done. A reasonable estimate is that you'll have a solution before Monday.

As for the generic overloads, we decided to reduce the surface area of the API to make it more maintainable. Since most people won't know the type of reflected members in advance it seemed reasonable to let go of the generic overloads and let people cast on the receiving end instead. The amount of code should also be much the same:

var s1 = (string) obj.GetFieldValue( "Name" );
var s2 = obj.GetFieldValue<string>( "Name" );
Coordinator
Feb 19, 2010 at 10:42 PM
Edited Feb 19, 2010 at 10:44 PM

I've checked in the TryGet/TrySet overloads - grab the latest source and let us know if you have any problems using them. Alternatively, look at the unit tests in TryGetSetTest.cs for a few samples.

Note that we kept the original throwing behavior of the access methods as it can be nice to be able to distinguish between cases such as "property existed and had value null" and "property did not exist".

Feb 20, 2010 at 5:44 PM

WOW that was fast! I will check these out as soon as I can. Thanks a lot.

Feb 22, 2010 at 11:53 AM
Edited Feb 22, 2010 at 12:11 PM

Great job! It works as expected.

Thanks for your effort!

Coordinator
Feb 22, 2010 at 4:51 PM

Thank you for the feedback!