Ayende @ Rahien

Ayende Rahien commented on Embracing fluent interfaces

Sat, 03 Nov 2007 19:47:50 GMT

I am saying that too much logic in the template is wrong, yes. You should have loops, a few ifs, but not much more. If you do have nested ifs or complex logic, it is time to extract it, and yes, it is entirely possible.

Mats Helander commented on Embracing fluent interfaces

Sat, 03 Nov 2007 19:30:03 GMT

"In fact, it this is how your HTML template looks like, this is not readable, and you need to rethink how you are doing it" Interesting! I must admit that's pretty much how all the examples I've seen of RoR, MonoRail etc have come across...but you're saying proper modularization gets rid of stuff like that? Completely? But are you in effect saying that someone using templates that look like that ^^ is doing it (RoR, MR) wrong? I may be totally off here, but I kinda think that's news...? /Mats

Ayende Rahien commented on Embracing fluent interfaces

Sat, 03 Nov 2007 16:22:31 GMT

Mats, Take a look at Brail's, it has a DSL for building HTML, as a matter of fact. In this case, it depends on what you are trying to do. Most cases, it is not just string generation. You can generate a sql statement with a template language: select * from Customers <% if has_conditions: %> where <% if first_name_starts_with: need_and = true %> firstname like @first_name_starts_with+ '%' <% end %> <% if last_name_starts_with: %> <% if need_and: %> and <% end %> lastname like @last_name_starts_with + '%' <% end %> <% end %> This is not readable. In fact, it this is how your HTML template looks like, this is not readable, and you need to rethink how you are doing it. But frankly, most of the time the HTML contains _very_ simple logic, rarely inter-related and rarely nested.

Mats Helander commented on Embracing fluent interfaces

Sat, 03 Nov 2007 16:16:39 GMT

So, basically you're saying that you wouldn't want to do string concat, but would rather use a DOM (which underlies the fluent interface)....but the same argument, I take it, still doesn't apply to building html? ;-) /Mats

Hongtao commented on Embracing fluent interfaces

Fri, 02 Nov 2007 06:25:23 GMT

Total agree with the second example, and that's why I still don't use the LINQ now.

Jeff Brown commented on Embracing fluent interfaces

Fri, 02 Nov 2007 01:44:16 GMT

I'm happy as long as the goal of the interface is to be composable not just verbose. The objectives of fluent interfaces are a bit muddy. They can introduce a higher level of abstraction along the lines of the Builder design pattern. However part of it is about introducing extra static type information and extra noise words for the sake of Intellisense support or RAD. There are many ways to accomplish the latter objective. Unfortunately we're a bit constrained by the languages and the tools here.

Lee commented on Embracing fluent interfaces

Thu, 01 Nov 2007 16:00:03 GMT

I couldn't disagree with jeff more. There is a fundamental concept that he is missing..... programming language are for humans, not computers (sort of speak). Otherwise we would be writing code in the equivalent to punch cards. 1. Fluent interfaces offer increase speed, if programmers could type faster without using intellsense then it wouldn't exist in almost every single modern IDE. 2. Fluent interfaces are a higher level form of abstraction, in a sense that's exactly why programming language were invented.

Luke Breuer commented on Embracing fluent interfaces

Wed, 31 Oct 2007 17:44:23 GMT

Your regex comparison isn't fair: split that regex onto multiple lines and use RegexOptions.IgnorePatternWhitespace. You do bring up a very interesting point, as my usual impulse is to go with compiler-checkable syntax. In the regex situation, I would prefer a multi-line, properly-indented, literal regex with IgnorePatternWhitespace. The regex fluent interface you've provided is ridiculously wordy compared to a regex. I've never really had to dynamically build regexes like I've had to do with SQL, so I'm probably unduly biased.

Ayende Rahien commented on Embracing fluent interfaces

Wed, 31 Oct 2007 17:04:21 GMT

Andy, Take a look at NHQG, I did some serious work there to that end.

Ayende Rahien commented on Embracing fluent interfaces

Wed, 31 Oct 2007 17:02:58 GMT

James, That depends on the implementation, but I don't think that regex's structured are exposed externally, so it probably build the string. Then again, this is the perfect place to put best practices into place.

Stuart Carnie commented on Embracing fluent interfaces

Wed, 31 Oct 2007 16:39:13 GMT

Ayende, I would have to agree with you. I have been experimenting with a fluent interface myself for our CRM platform. I have found that it is far easier to read, and IMHO maintain (as a side effect of improved readability). I also believe the learning curve is much simpler, due to using a syntax which includes operator overloads to allow: Where(Contact.Columns.Age > 18 && Contact.Columns.Age < 35 || Contact.Columns.Name.StartsWith("C"))

Andrey Shchekin commented on Embracing fluent interfaces

Wed, 31 Oct 2007 16:06:03 GMT

I think query in straightforward fluent interface can be as easy to read as the generated SQL: Prepare .SelectAll() .From() .Where(Tables.Customer.Country == "USA") .OrderBy(Tables.Customer.CompanyName).Ascending; But now I can do Prepare .SelectAll() .From() .Where(Tables.Customer.Country == "USA") .OrderBy(Tables.Customer.CompanyName).Ascending .Skip(5) .Take(10); and get a magic paging CTE under SQL Server and degradable behavior under other engines. Also Tables.Customer.Country == "USA" can be typesafe if Tables.Customer.Country is a QueryField.

James Curran commented on Embracing fluent interfaces

Wed, 31 Oct 2007 15:36:06 GMT

In the Regex example, is the result of the Fluent interface the string given in the first half? Or is it the Regex's internal structure? If the latter, then there could also be significant runtime savings as well.

Tim Scott commented on Embracing fluent interfaces

Wed, 31 Oct 2007 15:10:27 GMT

Besides readability, there is a big benefit of your fluent examples that you didn't mention. I have written a lot of complex searches like the one you mention using string concat to build SQL or HQL statements. I would like to think that I have done it cleverly, making the code reasonably understandable. Nonetheless, future developers must always take extra time when changing these methods...for one simple reason. The compiler is quite happy if put logic errors into string literals. What's it worth to catch errors at compile time versus runtime?

Dave Newman commented on Embracing fluent interfaces

Wed, 31 Oct 2007 08:06:42 GMT

Absolutely. Works fine for the simple scenarios, but I was on a project last year where the developers had vomited SQL all through the app, through every "layer". Trying to follow all the if/then logic to build an enormous SQL string to execute and identify injection problems was _not_ fun! This is for anyone writing code I may have to look at one day: If you're going to use SQL strings in your app people PLEASE wrap them in some kind of DAL class(s) so they're all in one place!