No idea - I don't write Ruby often :/

But inheriting your base from DynamicObject I can easily imagine how this will work.

@Aaron yeh that would work quite well in this situation as you say. How would this type of thing work in Ruby?

And it did! DOH! One more time, with HTML escape sequences ;-)

someFooHolder.Foos.Meets<CompletedFooSpecification>();

Maybe there is a good opportunity for Dynamic here :)

Something that converts the method name into the appropriate lambda dynamically... too magical?

Looks like the commenting engine striped out some of my example. This first example should be:

someFooHolder.Foos.Meets ();

Hope this doesn't get striped out also!

I agree with Jaco. When the LINQ expression is fairly simple and used frequently, then writing an extension method makes good sense. However, when the expression is complicated or composed of multiple, perhaps reusable parts, I like the Specification pattern: http://martinfowler.com/aps...

For example:

someFooHolder.Foos.Meets();

or

someFooHolder.Foos.Meets(new CompletedFooSpecification());

That may seem more involved - and it is. However, the specification pattern can give you (more) Separation of Concerns and composability, if you *need* it. If not, then extension methods is an good choice.

Interesting post - I agree that we tend to duplicate LINQ expressions quite often. If I find I'm re-using a LINQ expression I usually write a custom filter (extension method) and then simply re-use the extension method. The cool part about this approach is that you can unit test the filter and your code also becomes much more readable.

For example, you might write

users.WithId(5) instead of users.Single(u => u.Id == 5)