6 ms·

Why? It's a fluent interface.

• njbooher 14y ago
  It's not a verb.
  • kooshball 14y ago
    Using Select and Where makes perfect sense.
    • njbooher 14y ago
      Here it's a misuse of notation.
    • markokocic 14y ago
      In SQL it does.
      • kooshball 14y ago
        The whole point of LINQ is to add query-like functionalities to C#. LINQ stands for "Language-Integrated Query" from http://msdn.microsoft.com/en-us/library/bb397926.aspx 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."
    • pyre 14y ago
      ... only when used in sequence with the select. 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.
  • deleted 14y ago
    [deleted]
  • philwelch 14y ago
    Let me guess, you prefer methods called "getLength" over methods called "length", right? "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.
    • njbooher 14y ago
      No, I prefer objects with attributes called 'length'.
      • philwelch 14y ago
        Distinguishing between attributes and methods in your interface violates encapsulation. The only thing an object's interface should be worried about is what messages it responds to, it shouldn't have to expose whether it responds to messages by fetching a variable or calling a procedure. 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.
        • njbooher 14y ago
          Objects are nouns. They have attributes. Some of them can perform actions. Those actions ("verbs") are methods. It doesn't make sense to ask a noun to perform "where" or "length". Which part of this is confusing?
          • 14y ago