VB10 will have an “implicit line continuation” feature where the goal is that in the 98% case you won’t need to type the underscore anymore.

The case you mention though is one of those situations where it gets trickier for us to remove it, due to the ambiguity of With blocks.

Dim rect = RectangleFluent.Create()
.SetColor(Color.AliceBlue)
.SetHeight(16)
.SetLength(16)

If that code is inside a With block then we could parse it as one statement or 4 statements. We could make a rule to prefer one approach over the other, but that would just get confusing and messy.

Instead what we’ve done is allow the underscore to be implicit *after* the dot:

Dim rect = RectangleFluent.Create().
SetColor(Color.AliceBlue).
SetHeight(16).
SetLength(16)

Definitely not perfect, but we felt this was a reasonable compromise.

Hope that helps,

Jonathan Aneja
Program Manager, VB Compiler

Yes, there is no reason why I clever F# compiler could not have an extension operator to do just that. I’ve recently discovered that :: is treated as a special case by the compiler as it is actually a discriminated union constructor that expects a tuple but is allowed to act as an infix operated that is curried, so there is a precedent for such special cases.

I’ll suggest it to the product team.

I will have to look at why identions are not working in the comments, but i still get an unexpected symbol in binding when i try.

let rect =
RectangleFluent.Create()
.SetColor(Color.AliceBlue)
.SetHeight(16)
.SetLength(16)

Thanks for the link

I agree that pipelining methods is a more functional solution to fluency. Every method call in .net takes this as the first parameter. I wonder if the f# compiler could exploit this to allow for pipeling without the need for extension methods?

For the F# code in the last example, you could use:

let rect =
RectangleFluent.Create()
.SetColor(Color.AliceBlue)
.SetHeight(16)
.SetLength(16)

I’ve written a blog post about it a couple of months ago.

I think the reason that fluent APIs look ugly in F# is that they do not follow the functional paradigm. For example, you cannot easily compose functions using them. My solution has been to create static extension methods that wrap the API (fluent or not) and return the object. I will be demonstrating this approach with WPF on my blog soon (the code is done for that part, but not the supporting material).

I have not found a way round the ‘.’ problem, it does seem an oversight. Here’s an example using an extension method and a type T:


type T() =
member s.get() = () ; s

module Extension =
type T with
static member Get (s:T) = s.get()


Then you can write:


(T())
|> T.Get
|> T.Get


And also (T.Get >> T.Get) is a valid function.

However, it is a pain to write all those extension methods.

The middle ground is to write short “let” statements:


let x1 = new T()
let x2 = x1.get()
let x3 = x2.get()
x3


That is a bit extra code but it has a consistent structure, is strongly typed for the debugger at each step and is nicely formatted. Of course, you can batch statements too:


let x1 = new T()
let x2 = x1.get().get().get().get()
let x3 = x2.get().get().get()
x3