fluent interfaces
Mick Killianey
I've been modeling those classes on the hamcrest library.
Typical hamcrest code looks something like this:
AssertThat(8, Is(AllOf(GreaterThan(5),LessThan(18),Not(Prime())))
So qualified imports present a naming challenge: even a short package
name breaks up the flow:
import h "hamcrest"
h.AssertThat(8,
h.Is(h.AllOf(h.GreaterThan(5),h.LessThan(18),h.Not(h.Prime())))
I considered loading them all into the file scope in one fell swoop,
but I want to be very careful not to pollute the namespace, so the
simplest solution I can think of is to import packages with exactly
one symbol each:
import (
"hamcrest"
. "hamcrest/allof" // makes the AllOf matcher available in
this file
. "hamcrest/is" // the Is matcher
. "hamcrest/lessthan" // the LessThan matcher
...etc...
Is anyone else working on Go code with a fluent interface? Have you
discovered any particularly good tricks for this?
Bill Burdick
Esko Luontola
current scope. The assertion syntax looks like this:
https://github.com/orfjackal/gospec/blob/gospec-1.3.4/examples/expectation_syntax_test.go
Russ Cox
Maybe the problem is that this is not a "fluent interface".
There are no dots.
Oh, and by the way, Go has an expression syntax
that might just do the trick:
assert(x >= 5 && x < 18 && !prime(x))
Russ
Bill Burdick
chris dollin
The failure messages won't be so readable, though.
Chris
--
Chris "allusive" Dollin
Esko Luontola
"Probably the most important thing to notice about this style is that
the intent is to do something along the lines of an internal
DomainSpecificLanguage. Indeed this is why we chose the term 'fluent'
to describe it, in many ways the two terms are synonyms. The API is
primarily designed to be readable and to flow. The price of this
fluency is more effort, both in thinking and in the API construction
itself. The simple API of constructor, setter, and addition methods is
much easier to write. Coming up with a nice fluent API requires a good
bit of thought."
"I've also noticed a common misconception - many people seem to equate
fluent interfaces with Method Chaining. Certainly chaining is a common
technique to use with fluent interfaces, but true fluency is much more
than that."
Designing a fluent requires knowing all syntax tricks of the language
and using them to your advantage to achieve a nice syntax. So fluent
interfaces will be different depending on the language. For example
fluent Ruby or Scala will look very much different from fluent Java or
Go.
Esko Luontola
> mock.expects(once()).method("m").with(
> or(stringContains("hello"), stringContains("howdy")) );
>
> You can see that Fowler's use of stringContains() and or() are similar to
> the Hamcrest LessThan() and AllOf() expressions in Mick's example, although
> Fowler's example also chains methods.
extracted JMock.
Mikael Tillenius
e.g.
{
import . "hamcrest"
AssertThat(8, Is(AllOf(GreaterThan(5),LessThan(18),Not(Prime())))
}
Nothing from hamcrest would be visible outside the curly braces.
Suggestions on shorter and better syntax are welcome.
/Mikael
Mick Killianey
> > AssertThat(8, Is(AllOf(GreaterThan(5),LessThan(18),Not(Prime())))
>
> Maybe the problem is that this is not a "fluent interface".
> There are no dots.
interface...it's the *original* fluent interface.
> Oh, and by the way, Go has an expression syntax
> that might just do the trick:
>
> assert(x >= 5 && x < 18 && !prime(x))
sarcasm, that raises an interesting point.
An obstacle to the adoption of fluent APIs in Go will be that many of
the core libraries thus far have been written by people with an
extremely terse style. Fluent interfaces are a major style clash for
"tersers"...a clash that isn't endemic to Go (the language), but has
everything to do with personal tastes.
Broadly speaking, the "tersers" arrived first, but the "fluents" have
started to move in. I'm very curious to see whether they work
together or set up separate camps on the island...err...I mean, in the
language.
> Russ
Russ Cox
>
> See Chris Dollin's response re: better error messages, but as to your
> sarcasm, that raises an interesting point.
I wasn't being sarcastic. I don't see the point
of creating a separate syntax for writing expressions
when Go already has a rich syntax for writing expressions.
To automate error messages? I can write error messages
myself and then not have to learn (and continually extend)
some other testing language that isn't Go. I'd rather write
my tests and my code in the same language.
> An obstacle to the adoption of fluent APIs in Go will be that many of
> the core libraries thus far have been written by people with an
> extremely terse style. Fluent interfaces are a major style clash for
> "tersers"...a clash that isn't endemic to Go (the language), but has
> everything to do with personal tastes.
No. It has everything to do with writing Go versus
writing some other language mapped to Go function calls.
> Broadly speaking, the "tersers" arrived first, but the "fluents" have
> started to move in. I'm very curious to see whether they work
> together or set up separate camps on the island...err...I mean, in the
> language.
It's interesting that the fluents only move in on existing languages.
Where is the programming language written entirely in this
"fluent" manner, and why don't the fluents all use that one?
I suspect it is because you can't get any real work done,
only testing.
Russ
chris dollin
>>> assert(x >= 5 && x < 18 && !prime(x))
>>
>> See Chris Dollin's response re: better error messages, but as to your
>> sarcasm, that raises an interesting point.
>
> I wasn't being sarcastic. I don't see the point
> of creating a separate syntax for writing expressions
> when Go already has a rich syntax for writing expressions.
> To automate error messages? I can write error messages
> myself
Why, so can I, or so can any man --
> and then not have to learn (and continually extend)
> some other testing language that isn't Go.
It's just function calls; it's not a new language. It's a stylised way
of using the existing language, which pretty much any application
is.
As for the messages, while it's true that you can write [1]
if x < 5 {
bother( "expected", x, "to be less than 5" )
} else if x >= 18 {
bother( "expected", x, "to be less than 18" )
} else if prime(x) {
bother( "expected", x, "to be composite" )
}
I'd rather write something more like, if not exactly like:
AssertThat(8, Is(AllOf(GreaterThan(5),LessThan(18),Not(Prime())))
because the 17th time I wrote the former my head would
explode and my fingers start to smoke.
Chris
[1] `bother` being assumed to print its arguments nicely and quite the test.
--
Chris "allusive" Dollin
chris dollin
> because the 17th time I wrote
something like!
> the former my head would explode and my fingers start to smoke.
Chris
--
Chris "allusive" Dollin
Russ Cox
> bother( "expected", x, "to be less than 5" )
> } else if x >= 18 {
> bother( "expected", x, "to be less than 18" )
> } else if prime(x) {
> bother( "expected", x, "to be composite" )
> }
I'd have written
if x < 5 || x >= 18 || prime(x) {
t.Fatalf("invalid x: %d", x)
}
but this is not a common kind of check in a test.
I certainly have never written 17 such checks
in my life.
Can you point to places in actual Go tests
in the distribution where the so-called fluent
style would help? It seems like a solution in
search of a problem.
As far as I can tell, fluent coding is quite the misnomer.
It ignores the surrounding language instead of actually
using it idiomatically and, well, fluently.
Russ
chris dollin
>> if x < 5 {
>> bother( "expected", x, "to be less than 5" )
>> } else if x >= 18 {
>> bother( "expected", x, "to be less than 18" )
>> } else if prime(x) {
>> bother( "expected", x, "to be composite" )
>> }
>
> I'd have written
>
> if x < 5 || x >= 18 || prime(x) {
> t.Fatalf("invalid x: %d", x)
> }
Thereby not saying what test failed (yes, I know I can look
at the code and work it out -- I'd rather have the machine tell
me what it already knows).
> but this is not a common kind of check in a test.
> I certainly have never written 17 such checks
> in my life.
17 such AllOfs, nor me either. But at the smaller scale,
in JUnit tests I routinely use assertEquals (and a local
assertDiffers) rather than AssertTrue (or AssertFalse)
because of the better error messages, routinely create
assertWhatever methods when there's a meaningful
Whatever predicate that applies for the values in question,
and will happily write functions over the different Whatevers
(which amounts to being able to write the "fluent" expressions
in question).
> Can you point to places in actual Go tests
> in the distribution where the so-called fluent
> style would help?
No, but that only proves my current ignorance of the contents
of the Go tests.
> As far as I can tell, fluent coding is quite the misnomer.
> It ignores the surrounding language instead of actually
> using it idiomatically and, well, fluently.
I didn't (and possibly still don't) know what "fluent coding" is;
the Hamcrest-style being discussed is just, well, declarative-
style code written to be explicit about what it means, as far as I
can see. There's a bunch of library functions and you use them
to write things -- that some of them parallel existing language
structures is hardly surprising.
Bill Burdick
Mick Killianey
On Dec 15, 1:53 pm, Russ Cox <r...@golang.org> wrote:
> >> assert(x >= 5 && x < 18 && !prime(x))
>
> > See Chris Dollin's response re: better error messages, but as to your
> > sarcasm, that raises an interesting point.
>
> I wasn't being sarcastic. I don't see the point
> of creating a separate syntax for writing expressions
> when Go already has a rich syntax for writing expressions.
> To automate error messages? I can write error messages
> myself and then not have to learn (and continually extend)
> some other testing language that isn't Go. I'd rather write
> my tests and my code in the same language.
>
> > An obstacle to the adoption of fluent APIs in Go will be that many of
> > the core libraries thus far have been written by people with an
> > extremely terse style. Fluent interfaces are a major style clash for
> > "tersers"...a clash that isn't endemic to Go (the language), but has
> > everything to do with personal tastes.
>
> No. It has everything to do with writing Go versus
> writing some other language mapped to Go function calls.
larger than your vision of it.
> > Broadly speaking, the "tersers" arrived first, but the "fluents" have
> > started to move in. I'm very curious to see whether they work
> > together or set up separate camps on the island...err...I mean, in the
> > language.
>
> It's interesting that the fluents only move in on existing languages.
> Where is the programming language written entirely in this
> "fluent" manner, and why don't the fluents all use that one?
> I suspect it is because you can't get any real work done,
> only testing.
useful when writing tests.
Your opinion that writing tests isn't real work is uninformed.
When incorrect code puts valuable things at risk, the amount of test
code far outstrips the amount of production code. (My experience has
been 5:1 test:production.) I've never worked at NASA, but I expect
that when a piece of software takes two years to reach its target, you
write a *lot* of tests to make sure nothing ruins a multi-billion
dollar project.
So if you see the "fluents" moving in, it's because they *are* doing
real work...they're using the appropriate tools to make sure your
child's/spouse's/parent's life-support system at the hospital never,
ever fails.
If you don't see so many fluent languages in the early stages of
language development, perhaps that's because there are very few
mission-critical consequences when things go wrong. Who cares if you
break a prime number sieve?
> Russ
Mick Killianey
I should also add to this that I think that the Go team (and the Go
community) has done some really wonderful work and I'm very much
enjoying their young creation. So if I seem to want to pick up the
ball and run with it, that's not because I don't want to play, or
because I think that the Go team is going in the *wrong* direction.
I'm just speaking up because I'm aware that my needs and wants take me
in a different direction, and I think highly enough of Go that I'd be
chuffed to have it with me as I go my merry way. Yay, Go!
While I'm passing out the kudos, a big shoutout to gocode and
goclipse...two much-appreciated tools that really complement each
other.
Cheers!
> > Russ