About RSpec and Watir: I’ve been wrestling with an parser for Wiki syntax for the last 7 years without success. Writing parsers is currently very hard. Because of this, Radeox as a wiki engine has still a regex ‘parser’ no real parser.

People like Ruby because they can create a language without a parser. When there are easy parser tools for the JVM or CLR – and Tatoo is certainly a first step – every developer can writer a parser which ‘maps’ a DSL to a base language on the JVM or CLR. Then Ruby with it’s language defining abilities will look much less adorable.

And after 15 years with dynamic languages (TCL, Perl, Python, Ruby) I it will be a very hard way to make great IDEs for them. The current Grails/Groovy support in IDEA is the best you can get – and it’s nice. But poor compared to the Java support. They can gather runtime information to make the IDE understand the code better, though I guess there are some natural limits to that.

At least in C#, an entire block of fluent interface code done through method chaining counts as one line of code to the debugger, so you don’t know which method call in the chain is giving you issues. This can get extremely annoying when you have particularly large fluent interface blocks.

I think fluent interfaces are becoming popular because:
- Building real (or external) DSLs is hard
- Still no solid cross-platform dynamic language support, i.e. JRuby or IronRuby
- Fluent interface APIs can be used with familiar languages like Java and C#

We use NUnit a lot, but get very jealous when we see our QA guys using RSpec and Watir. All of the noise of the syntax goes away and it becomes much more readable. But until these dynamic languages can run easily in the JVM or the CLR, and have great IDE support, fluent interfaces are definitely the way to go.

I think a fluent interface uses several patterns and provides several solution. The solutions can be Building-of-objects or can be modelling business logic (mostly when used with closures). As Java does not support closures yet, most fluent interface applications currently fall into the builder domainBeside that another pattern fluent interfaces use is the Facade pattern. But fluent interfaces are more than variants on facades and builders. They are a mixture of DSL, builders, facades, readable APIs, context selection and other ideas. So yes in this case it’s mainly a builder implementation. Not in other cases though.

I thought about the finish() method. Usually I use a create() or make() method and would like to use do() for executing filters (Java doesn’t like do though). But sometimes I find it more fitting to exend the base class and drop the creation method call as a last call in the chain.

Iterable filtered =
Iterables.with(names)
.addFilter(or(isEqualTo(“Chris”), isEqualTo(“Miha”)))
.addFilter(lengthLessThan(5))
.finish();

The idea is that all the intermediate objects should be instances of IterableBuilder, which has the “fluent” methods. The finish() method converts an IterableBuilder back to a plain Iterator. This way the “fluent” methods don’t clutter up the interface when you’re not modifying the Iterable.

Also, if there is an IterableBuilder object then I think it’s fine to modify-in-place rather than creating a new instance on each method call, which may be important for performance.

To tell you a secret, I’ve thought about the same thing. When writing about fluent interfaces for object creation

http://stephan.reposita.org/archives/2007/10/10/fluent-interface-and-reflection-for-object-building-in-java/

I was wondering if fluent interface is a concern of the Person bean which it creates or if it’s a different concern. When this should be the case, a different class called PersonFluentInterface is good practice, as each class should encapsulate one concern, not different ones. This also makes the Person bean smaller and easier to understand. When being interested in the fluent interface, one could look into PersonFluentInterface and see the methods and code – and not be confused with the Person concerns.

“Anyway, though, as time permits I’ll draw up a three-way comparison of the apis and see if we can shake out which one’s best.”

That would be great and I would be interested in the result. Thanks for your comment.

The other fix that I had in mind: make Function and Predicate into abstract classes which have the transform(), filter(), and other related methods right there on them. To me, this is a much more sound idea from an OO perspective than saying you have to go call out to some static “Iterables” method (which is entirely nonobvious).

As well, it means that in the resulting code, filters and transforms appear in “infix”, not prefix form, which I find a lot easier to read.

The down side of all this: *occasionally*, but not often, someone does want to implement Predicate/Function from an existing class that already has a superclass, thankyouverymuch. There are some ways we could deal with that, though. Anyway, though, as time permits I’ll draw up a three-way comparison of the apis and see if we can shake out which one’s best.