-
Notifications
You must be signed in to change notification settings - Fork 102
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
Add producer convenience methods #632
Conversation
7b5d7bd
to
36c2941
Compare
This looks great! Just one thing - adding these as instance methods is going to break binary compatibility, so I'm thinking it would be better to have them as extension methods implemented in terms of |
Should be do-able, where would you place said extension methods? |
I'd say an implicit class in companion object so they're always available. It'll need some kind of typeclass available at the usage site (I think |
def produceOne_(record: ProducerRecord[K,V]): F[F[RecordMetadata]] = { | ||
produceOne(record, ()).map(_.flatMap { res => | ||
val metadata = res.records.head.map(_._2) | ||
MonadError[F,Throwable].fromOption(metadata, new IllegalStateException("Exactly one record metadata expected")) |
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.
Is this the only reason we need MonadThrow
? If so I'd be inclined to just throw an exception here, since this should never happen.
Sorry, forgot about this - I was thinking it would be the same as the existing
That requires |
One other thing I forgot - can you make the ops class extend |
Doing so I get |
iirc the |
I get the same error with that |
Yes, to use Also, I would add tests for each method. These tests could be dumb, but each new method should be called in tests. Because these multiple overrides could lead to runtime issues with erasure, especially after refactorings. |
Right, yeah. On second thought, maybe these should just be |
Personally not strong opinions, happy to do whichever folk reckon is best :) |
I think erasure issues should show up at compile time? But yes, it would be good to at least see that code using these compiles. |
I'm on the |
I don't have a strong opinion so let's go with that 🙂 |
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 - thanks!
Per suggestions in #446
Tests are def a bit anaemic, wasn't sure what the right balance between exhaustivity and maintainability was.
Didn't include a
pipe
method as suggested in the original issue as was not clear what the semantics should be (flatten theF[F[...]]
?), but happy to add if clarified.