-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nicer infix operators? #262
Comments
Changing the existing module is indeed not an option. However, I am all for a redesign (under a new name — say, Test.Tasty.HUnit2) with better names etc. There are also some functions/operators that I miss:
So if you feel like having a go at redesigning the HUnit module with the above considerations in mind, please do. |
So if such a patch were to appear, there is a reasonable expectation that it will be merge? If such is the case, then I am putting it in my to do list. |
Yes, I think we've been stuck with the original HUnit design for too long, so a well designed replacement would be welcome. |
I would like to second more assertion primitives, e.g. appreciate something like Additionally, in my opinion real names are preferable to infix operators. Especially when others such as |
Is this still open to PRs? I'd like to implement |
This is by design so that Instead of reimplementing |
Yes, that was what I initially thought... the divide between |
I know there is a strong sentiment in the Haskell community towards legacy support, backwards compatibility and so on, and I am prepared to discover that this is a "wontfix", but I would like to express my vote anyway.
HUnit has operators
@?=
and@=?
. I propose we change them to?=
and=?
— it would be so much more readable and intuitive. (Which side the question, the same side the value being checked.) Hoogle does report a couple of packages using these names, but I claim that a test engine is used far more widely (ideally, in every package) and so it is fair to have the shorter names.Let us redefine
QuickCheck.===
to mean extrinsic equality for functions:f === g = \x -> f x == g x
. Properties are quite often expressed as equality of functions anyway — think of the laws of any standard class.Consider that any function benefits from an example and, better, a property too. So these operators might be used more often than any other function at all, and every small nuisance is magnified.
The text was updated successfully, but these errors were encountered: