-
Notifications
You must be signed in to change notification settings - Fork 325
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
Introduce VersionNumber newtype. #3075
Conversation
See `/libs/wire-api/test/unit/Test/Wire/API/Routes/Version.hs` for explanation.
2017a86
to
31c9889
Compare
.hlint.yaml
Outdated
# . allVersionNumbers @=? cs . toByteString' | ||
# <$> allVersionNumbers) | ||
# ``` | ||
- ignore: { name: Functor law } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we don't want to ignore Functor law
everywhere, but rather where hlint gets tripped up, which seems to be when using the Bilge Assert combinators? 🤔
I wish hlint made it easy for us to disable some stuff per module/target.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to turn off broken laws. It's not like either side of the law is wrong, it's merely an aesthetic preference. Anyone case to weigh in either way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's just me who sometimes write "dumb" functor code and waits for hlint to clean it for me. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I comes to dumb mistakes, I'm a good candidate, too 😉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, i'm outweighed. :) will fix!
deriving (Arbitrary) via (GenericUniform Version) | ||
|
||
versionString :: IsString a => Version -> a | ||
versionString V0 = "v0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this could be implemented with fromEnum
.
The benefit would be that you won't have to touch this function when a new version is introduced. The drawback is that Version
constructors have to be sorted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i used to agree, but been there! :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This simple version is fine with me, too 😸
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But surely it could be implemented in terms of versionInt
.
versionString V2 = "v2" | ||
versionString V3 = "v3" | ||
|
||
versionInt :: Integral i => Version -> i |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here: Could be implemented with fromEnum
.
parseVersion :: Request -> Maybe (Request, Integer) | ||
data ParseVersionError = NoVersion | BadVersion Text | ||
|
||
parseVersion :: Request -> Either ParseVersionError (Request, Version) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if this function cannot be generalized regarding its Monad: Shouldn't a constraint MonadError m => ...
be sufficient?
(This is nitpicking as far as nitpicking can get ... 😉 )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, that would be sufficient, but i intentionally decided against it. i like both the abstract interpretation and the precise type that offers exactly what's needed, and not more.
always happy to nit-pick, though! :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Being able to state if we're referring to an API version or only its number seems to be an improvement to me. 👍
Please feel free to get into my nitpicks or ignore them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just unsure about the hlint changes, although not a blocker.
Co-authored-by: Sven Tennie <sven.tennie@wire.com>
This reverts commit 31c9889.
…ypes' into play-with-version-types
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would organise this differently:
- I wouldn't use the
Enum
instance ofVersion
to define the schemas, as that is bound to cause confusion. Instead, we can have a listallVersions :: [Version]
somewhere and use that. In fact, we should probably remove theEnum
instance. versionString
andversionInt
can then be defined in terms of the schema instance, as they were (implicitly) before.
deriving (Arbitrary) via (GenericUniform Version) | ||
|
||
versionString :: IsString a => Version -> a | ||
versionString V0 = "v0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But surely it could be implemented in terms of versionInt
.
I don't disagree, but I don't understand either: what's the confusion that is caused by the I think |
Happens reproducibly on CI, but I can't reproduce it locally.
|
retried to reproduce locally (only the one test) 15878 times. got the sibling test to fail locally after 57 re-runs:
|
ok, we established the test is flaky and unrelated. i'll merge once i get lucky with the re-runs. |
…-test' into play-with-version-types
(I ran this against develop to establish this tests the right thing.)
8e02002
to
759750f
Compare
|
* Introduce VersionNumber newtype. See `/libs/wire-api/test/unit/Test/Wire/API/Routes/Version.hs` for explanation. Co-authored-by: Sven Tennie <sven.tennie@wire.com> Co-authored-by: Paolo Capriotti <paolo@capriotti.io> Co-authored-by: Stefan Matting <stefan@wire.com> Co-authored-by: Leif Battermann <leif.battermann@wire.com>
See
/libs/wire-api/test/unit/Test/Wire/API/Routes/Version.hs
for explanation.Checklist
changelog.d