Conversation
There was a problem hiding this comment.
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
HotswapAPI 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. |
armanbilge
left a comment
There was a problem hiding this comment.
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.
Sorry if I'm missing something, what is this sentence referring to exactly?
There was a problem hiding this comment.
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.
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.
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.
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 🤞🏻 |
djspiewak
left a comment
There was a problem hiding this comment.
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
Hotswapso it conforms to theHotswapAPIAddresses #4268