in c#3.0 we write
string.Join("\n", mylist.Select(x=>x.Description()).Where(x=>x != "").ToArray());
string.Join("\n", mylist.Select(x=>x.Description()).Where(x=>x != ""));from http://msdn.microsoft.com/en-us/library/bb397926.aspx
"Language-Integrated Query (LINQ) is a set of features introduced in Visual Studio 2008 that extends powerful query capabilities to the language syntax of C# and Visual Basic. LINQ introduces standard, easily-learned patterns for querying and updating data, and the technology can be extended to support potentially any kind of data store. Visual Studio includes LINQ provider assemblies that enable the use of LINQ with .NET Framework collections, SQL Server databases, ADO.NET Datasets, and XML documents."
I'm thinking that complaint is that something like (e.g.) "Filter" would mean the same thing and be a verb describing the action being taken.
"Method names should be verb phrases" is one possible convention, but it's not the only convention. If you can get better code by violating that convention, then the convention is, in that instance, wrong. Using verb phrases for function names is more of a procedural programming technique that doesn't always translate to object-oriented programming. In this particular instance, having a more declarative interface is more readable.
On the implementation side, if you just want to expose a variable then attributes are fine. Outside of your object, though, who cares whether or not "length" is an attribute? Maybe your object is encapsulating a lazily-evaluated database relation, at which point "length" would generate a SELECT COUNT query. It still fulfills the contract of "an object that has a length", and you don't want to get in the business of defining different interfaces for "an object that has a length cached in an instance variable" and "an object that has a length that is calculated dynamically".
The properties of an object are best expressed with noun phrases regardless of their implementation.
It's much simpler and more effective to think of objects as things that respond to messages. So instead of thinking it as asking the object to perform "where" or "length", think of it as sending the message "where" or "length" to the object and potentially receiving a response. This way you can expose more flexible and declarative interfaces, and let the object worry about which properties it computes on demand and which properties it caches or stores in instance variables.
You do have to consciously do this in C-derived languages, though. But it's easily possible.
If anything, it introduces unnecessary semantics to syntactically distinguish between messages that are responded to with instance variables and messages that are responded to with function calls.