On Tuesday, 8 May 2018 at 07:07:30 UTC, Nick Sabalausky
(Abscissa) wrote:
On 05/07/2018 11:57 PM, Johannes Loher wrote:
On Monday, 7 May 2018 at 09:19:31 UTC, Dechcaudron wrote:
I think I'm siding with Johannes here. Much as the overloads
look nice, I don't really see the advantage over
`shouldEqual`. Also, what's with `all.these.identifiers`? Any
particular reason why you are more fond of them rather than
of good ol' pascalCase?
Fluent assertions have one major advantage over using
pascalCase assertions: There is no ambiuguity about the order
of arguments.
When using e.g. assertEquals, how do you know wheter is is
supposed to be assertEquals(actual, expected), or
assertEquals(expected, actual)? The first one is the only one
that makes sense wirh UFCS, but it is not clear directly from
the API. On top of that, some popular Frameworks (I‘m looking
at you, JUnit...) do it exactly the other
way round.
With fluent assertions, you don‘t have this Problem, it is
much more clear that it should be
actual.should.equal(expected) and not
expected.should.equal(actual), because it fits naturally in
the chain of ufcs calls.
I don't think that's the issue. At least, it isn't for me.
It's not a question of "assert equals" vs "should equal"
(Though I am convinced by your argument on that matter).
The question is: Why "should.equal" instead of "shouldEqual"?
The dot only seems there to be cute.
Not that I'm necessarily opposed to any of it (heck, I like
cuteness in any sense of the word), it's just that: If the "~"
thing is operator abuse, then I don't see how "should.equal",
"should.not.be" etc, wouldn't fall into the same category.
I wouldn't say it's an abuse, the dot means exactly the same
thing as everywhere else in the language. I'm way less fan of
overidding ~ since that doesn't have that meaning in any other
context.
Without having actually used it, I like the composability over
pascalCasing here, it looks like it fits nicely in a functional
environment with things like aliases and partials I think,
defining your own primitives naturally... Nothing one can't do
with regular functions and pascalCased assertions, but it sounds
like it would be way more verbose.
It also sounds like it's easier on the implementation side since
you never have to define both a "shouldSomething" and
"shouldNotSomething", and that means as a user I can expect less
bugs and better maintainance of the library.
That said, it'll have to be field-tested to be sure.
