Pass arguments as lambdas?

Nov 9, 2011 at 8:40 AM

Great library!

I do have a couple of minor suggestions though...

1. Add overloads so we can pass arguments as lambdas and the library can get the argument name / value from there...

public Foo(Bar bar)
    Condition.Requires(() => bar).IsNotNull(); = bar;

I really dislike using literal strings for passing argument / property names so I've rolled my own Condition wrapper to add this, but it'd be nice to see it in the library.  I'm happy to share my code if you like but you can probably find examples of how to do it.

2. Add a .NET 4 assembly - I know I can grab the source and retarget it but would be nice if it was distributed with both 3.5 and 4.0 versions.  I'm using the NuGet distribution.


Nov 9, 2011 at 8:52 AM


I've had a discussion about the use of lambda's in the past. Because of the performance implications I decided not to implement this. You can read more about this motivation on this thread on the Codeproject site. If it's of any help, the library ships with code snippets that make writing these lines much easier. After installing the code snippets, you can write "requires [TAB] [TAB]" to insert the snippet.

CuttingEdge.Conditions can be used with .NET 2.0. It is compatible with .NET 4.0. Can you explain why you need a 4.0 version?




Nov 10, 2011 at 12:42 AM

Thanks for the quick reply.

Apologies for bringing up an old issue again.

I understand your hesitation regarding the performance of the lambda expressions, but I'm not suggesting that it should replace what currently exists in your library, I was suggesting it as an additional overload and then it's up to the developer to use it or not.  In some cases it's ok to trade a little performance to decrease the code's maintenance burden and if performance does become a problem then we can revert to one of the other overloads or the good old if then throw...

I don't need a .NET 4.0 version, I would just feel better using a .NET 4.0 library in my .NET 4.0 projects.  Most other dependencies I'm using have separate assemblies for .NET 3.5 and 4.0, but I know a .NET 3.5 assembly will run perfectly fine in a .NET 4.0 process, although I'm not entirely sure how this works under the covers or whether there are any performance issues with loading both frameworks into the one process (if that's what happens).  Beyond that there's no real concrete reason why I want this.


Nov 10, 2011 at 9:03 AM
Edited Nov 11, 2011 at 6:28 AM

With the early beta's it was pretty easy to add this overloaded methods yourself, by adding extension methods in a root namespace. Since the first stable release however, it isn't that easy anymore. You need to add a custom class (something like MyOwnCondition.Requires), which of course is very inconvenient. Besides that, you make a fair argument about giving developers a choice. I'm afraid however, that developers would pick this overload too easily, getting themselves into trouble because of the performance problems it causes (and don't forget that your assembly will get considerably bigger when using this throughout the code base). I rather prevent them from doing this in the first place.

Don't forget that the only problem you solve with this overload is that that ParamName argument of the thrown ArgumentException stays with the method argument when you rename it. Without this feature, you need to change the method argument name in two places, but they are always very close to each other. Although this not optimal, it isn't much of a loss in maintainability. Besides, forgetting to change the "argName" string a Requires call will not break the application (unless your application depends on the ArgumentException.ParamName property, which is of course a bad thing), just make the thrown exception a bit less obvious.

About .NET 4.0: you can use CuttingEdge.Conditions without any problem in your .NET 4.0 projects. .NET will not load both the .NET 2.0 and .NET 4.0 assemblies; it will just load the .NET 4.0 assemblies in your case. You don't have to worry about any performance problems because of that. Rather worry about the performance problems caused by a Requires(() => arg) overload ;-)

Marked as answer by dot_NET_Junkie on 8/14/2014 at 12:35 AM
Nov 11, 2011 at 1:10 AM

Fair enough.