-
Notifications
You must be signed in to change notification settings - Fork 556
Add NonEmptyHotswap #4267
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 NonEmptyHotswap #4267
Conversation
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.
Thanks for the PR!
Honestly, I wonder if we should deprecate the old HotSwap
.
Hotswap[F, A]
is justNonEmptyHotswap[F, Option[A]]
. We don't need both.- The current
Hotswap
API is broken anyway, e.g. see #3480 (comment).
@djspiewak I know you hate it, but there are so many things we could fix if we just embrace the ugly Hotswap2
, Queue2
, 😅
Oh, also you should retarget to series/3.6.x
if you want it to make the next release (@djspiewak are we still merging new APIs into this branch?)
std/shared/src/main/scala/cats/effect/std/NonEmptyHotswap.scala
Outdated
Show resolved
Hide resolved
std/shared/src/main/scala/cats/effect/std/NonEmptyHotswap.scala
Outdated
Show resolved
Hide resolved
std/shared/src/main/scala/cats/effect/std/NonEmptyHotswap.scala
Outdated
Show resolved
Hide resolved
11ca512
to
e9965a3
Compare
Thanks to armanbilge for the [suggestion](typelevel#4267 (comment))
sttp has embraced this path a long time ago and it works like a charm :) https://github.com/softwaremill/sttp/tree/master/core/src/main |
@armanbilge did you want the |
I do, but I'm not sure if @djspiewak has bought in. |
@djspiewak could we get a ping if this is something you'd like to weigh in on? |
@armanbilge it's been 6 weeks without a ping from @djspiewak, can we take that as "decline to comment" and proceed? |
@armanbilge no shade intended by this question, just want to know if I should close it: is this a dead PR? |
@morgen-peschke review and release cycles in Cats Effect are often very slow, sorry about that, and thanks for your patience |
@armanbilge what's the culturally acceptable frequency of comment-bumping a PR in this state? I'd really like to offload having to remember to check back on this to a repeating calendar event and I also don't want to be a bother by posting too often just to keep the PR from sliding completely off the radar, if the expectation is that this could be another 3+ months. ETA: In case the above came across wrong, I want to reiterate that no slight is intended, I'm trying to figure out the best way to manage the time and energy I'm going to spend keeping track of this PR, as well as avoid creating the association in y'all's mind as that annoying dev who won't shut up about that one PR. |
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 spoke to Daniel offline, he is alright with moving ahead with Hotswap2
. Thanks for your patience!
I just noticed ... we will need to retarget this PR at series/3.x
and I think this will require rewriting the test suite using munit, sorry about that!
docs/std/hotswap.md
Outdated
## Hotswap | ||
|
||
In cases where the managed `Resource` may be missing, `Hotswap` provides some optimizations for this use case. |
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.
Sorry if I'm missing something, what is this sentence referring to exactly?
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.
It's referring to some of the stuff that Hotswap
does around avoiding blocking swap
after a call to get
returns a Resource
containing a None
.
If we're fully deprecating Hotswap
, we can probably drop this section entirely.
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 we can fully deprecate Hotswap
in favor of Hotswap2
.
Hotswap2.create[F, R].map { nes => | ||
new Hotswap[F, R] { | ||
override def swap(next: Resource[F, R]): F[R] = | ||
nes.swap(next.map(_.some)) *> get.use(_.get.pure[F]) |
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 is the "leaking" implementation, correct? Maybe we should add a comment saying this is intentional, to satisfy the mistakes of the old api.
* [[swap]] finalizes the previous resource immediately, so users must ensure that the old `R` | ||
* is not used thereafter. Failure to do so may result in an error on the _consumer_ side. In | ||
* any case, no resources will be leaked. | ||
* | ||
* For safer access to the current resource see [[get]], which guarantees that it will not be | ||
* released while it is being used. |
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.
These docs can be updated, they are trying to massage around the shortcomings of the old API.
Squash - Deprecate Hotswap - Apply suggestions from code review Co-authored-by: Arman Bilge <armanbilge@gmail.com> - Remove unsafe returned value from swap - prePR - Implement Hotswap in terms of NonEmptyHotswap - Also adds two methods to make `NonEmptyHotswap` a drop-in replacement for `Hotswap` - Revert "Implement Hotswap in terms of NonEmptyHotswap" - This reverts commit 8dc9fcf. - Add a not about the differences between Hotspot and NonEmptyHotspot - Revert "Add a not about the differences between Hotspot and NonEmptyHotspot" - This reverts commit bcfb4b0. - Revert "Revert "Implement Hotswap in terms of NonEmptyHotswap"" - This reverts commit 4b7ebe4. - Implement lock aquiring shenanigans and restore related test Thanks to armanbilge for the [suggestion](typelevel#4267 (comment)) - Switch NonEmptyHotswap to Hotswap2 - Apply suggestions from code review Co-authored-by: Arman Bilge <armanbilge@gmail.com> - Deprecate Hotswap - Documentation fixes in Hotswap2 - Add Hotswap2.getOpt This would allow upgrading from Hotswap without losing the semantics of not acquiring a lock when no resource is present for `Hotswap2[F, Resource[Option[R]]]`
a49624e
to
bfadf2b
Compare
Squash - Deprecate Hotswap - Apply suggestions from code review Co-authored-by: Arman Bilge <armanbilge@gmail.com> - Remove unsafe returned value from swap - prePR - Implement Hotswap in terms of NonEmptyHotswap - Also adds two methods to make `NonEmptyHotswap` a drop-in replacement for `Hotswap` - Revert "Implement Hotswap in terms of NonEmptyHotswap" - This reverts commit 8dc9fcf. - Add a not about the differences between Hotspot and NonEmptyHotspot - Revert "Add a not about the differences between Hotspot and NonEmptyHotspot" - This reverts commit bcfb4b0. - Revert "Revert "Implement Hotswap in terms of NonEmptyHotswap"" - This reverts commit 4b7ebe4. - Implement lock aquiring shenanigans and restore related test Thanks to armanbilge for the [suggestion](typelevel#4267 (comment)) - Switch NonEmptyHotswap to Hotswap2 - Apply suggestions from code review Co-authored-by: Arman Bilge <armanbilge@gmail.com> - Deprecate Hotswap - Documentation fixes in Hotswap2 - Add Hotswap2.getOpt This would allow upgrading from Hotswap without losing the semantics of not acquiring a lock when no resource is present for `Hotswap2[F, Resource[Option[R]]]`
bfadf2b
to
e114c7d
Compare
Squash - Deprecate Hotswap - Apply suggestions from code review Co-authored-by: Arman Bilge <armanbilge@gmail.com> - Remove unsafe returned value from swap - prePR - Implement Hotswap in terms of NonEmptyHotswap - Also adds two methods to make `NonEmptyHotswap` a drop-in replacement for `Hotswap` - Revert "Implement Hotswap in terms of NonEmptyHotswap" - This reverts commit 8dc9fcf. - Add a not about the differences between Hotspot and NonEmptyHotspot - Revert "Add a not about the differences between Hotspot and NonEmptyHotspot" - This reverts commit bcfb4b0. - Revert "Revert "Implement Hotswap in terms of NonEmptyHotswap"" - This reverts commit 4b7ebe4. - Implement lock aquiring shenanigans and restore related test Thanks to armanbilge for the [suggestion](typelevel#4267 (comment)) - Switch NonEmptyHotswap to Hotswap2 - Apply suggestions from code review Co-authored-by: Arman Bilge <armanbilge@gmail.com> - Deprecate Hotswap - Documentation fixes in Hotswap2 - Add Hotswap2.getOpt This would allow upgrading from Hotswap without losing the semantics of not acquiring a lock when no resource is present for `Hotswap2[F, Resource[Option[R]]]`
87b5ce7
to
e8f3003
Compare
@armanbilge the test failure appears to be unrelated to this change, if everything else looks good, can you retrigger CI? If something needs changed, don't worry about it, since it should clear on the next push 🤞🏻 |
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 there a reason we moved away from NonEmptyHotswap
as a name? Aesthetically that seems better to me than Hotswap2
. We could still deprecate Hotswap
even in that world.
This isn't something I have strong opinions about, so you'll have to check in with @armanbilge for the reasons behind it. Context: originally raised in this comment, I swapped the names because it was requested by the primary reviewer, I couldn't think of a good reason not to do it, and I didn't want to hold up the PR. |
I don't want to hold this up over aesthetic concerns 😁 if The reason I suggested |
Also corrects the site docs for
Hotswap
so it conforms to theHotswap
APIAddresses #4268