No Backwards Compatibility conditional compilation symbol

rxelizondo posted on Monday, November 30, 2009

Today I ran into a relatively minor but annoying issue, I coded the following by mistake:

ValidationRules.AddRule(Csla.Validation.CommonRules.StringRequired, Description);

Instead of the correct:

ValidationRules.AddRule(Csla.Validation.CommonRules.StringRequired, DescriptionProperty);

In the first line of code I used “Description” while in the second one I used “DescriptionProperty”. The first one (Description) is basically a call to the implementation of my property:

public string Description
{
get { return GetProperty(DescriptionProperty); }
set { SetProperty(DescriptionProperty, value); }
}

So basically, in the first “AddRule” call, I was using the overload that take a string as the property name and I was using whatever string my Description property was returning (an empty string).

In the second “AddRule” I was using the PropertyInfo object which is what I always indented to use in the first place.

It’s a simple enough mistake that could have been easily detected while compiling the code if the “AddRule” overload that takes a string for the property name would not exist.

As far as I understand, this overload is there simply for backward compatibility. So ideally, I would like to see this type of backward compatibility code surrounded by a conditional compilation symbol that would instructs the compiler to ignore that chunk of code.

This way, people that don’t care about backwards compatibility can set that conditional compilation symbol to true and be done with it. Also, most importantly, new CSLA programmer would be spared of having to figure out what is going on if they made the same mistake.

Just a suggestion of course, no biggie. That with a combination of obsolete attributes would be pretty nice I think.

ajj3085 replied on Monday, November 30, 2009

I could be wrong, but I don't think its legacy / obsolete.  There's a real overhead to using PropertyInfo / FieldManager, and people may choose to use the private backing field method, which would necessitate this overload.  Maybe it's changed and I'm not aware though.