:loudspeaker: :loudspeaker: :loudspeaker: Don't ...
# arrow
s
📢 📢 📢 Don't miss the webinar today at 17:00 CEST. Building applications with Kotlin and Arrow.kt in style by @simon.vergauwen https://www.47deg.com/events/building-applications-kotlin-arrow-may-31-2022/ Slack Conversation
🙌 2
❤️ 7
g
that’s good stuff!
🙏 3
y
I was on the edge of my seat when the multi-context
with
was mentioned! I felt star-struck seeing a workaround that I found actively being used and resulting in (slightly) neater Kotlin code :) thankfully that bug is getting fixed in 1.7.20 though so hopefully multi-context
with
will be part of the stdlib soon!
p
thanks for the great talk I really liked it!
s
I just found some time to actually sit down and watch this and I must say you've done an amazing job, this was so pleasant to watch. I didn't even realize when 50 minutes had passed! I was so happy with how you had explained everything. After using Arrow for only a few months this was already very understandable, there wasn't a single moment where I felt like something wasn't clear! Out of the entire thing, the only thing that didn't sit well with me was making the functions practically return a different type than what the function signature said, with the addition of wrapping it in the context of an
EffectScope<DomainError>
but that's something I'd love to hear more community discussions about. But that's a mild detail if anything.
y
@Stylianos Gakis Consider it sort of like checked exceptions: functions that have a
context(EffectScope<DomainError>)
declare that they need the caller to be able to handle errors of type
DomainError
. It's just asking for an error handler, which is quite a common pattern already.
s
I can totally consider them as “sort of like checked exceptions” but I do not like checked exceptions so that’s not helping 😅 I understand that a case where you can not call this from the wrong context and that is awesome. What I do not like is the fact that when glancing over a function signature I would then need to take an extra step and look at the context it needs to be in to understand what the return type is. Add on top of that typealiases which I also very much dislike as I pretty much 100% of the time feel the need to jump to their declaration to ensure what they’re hiding behind, then we’ve gone from glancing over the function signature and understanding everything to doing one step to understand what the happy path return type is, a second step to check which context it can be called from, and a third step to jump to the typealias declaration to understand what that is all about. I might change my mind about this in the future, but at the moment that’s how I feel about it.
👍 1
s
Hey @Stylianos Gakis, thank you for the kind words 🙏 About
EffectScope
vs
Either
, perhaps I should've been more explicit in the webinar. I am not suggesting that using
context(EffectScope<E>)
is better than returning
Either<E, A>
. Like a lot of things in software, it's more about the properties of the pattern. In this case, the expected error is typed
E
rather than an implicit
Throwable
. Either style holds that property so I would say it's purely a matter of preference. I gave the same answer here, https://stackoverflow.com/questions/72277426/which-should-we-choose-between-effect-an[…]either-as-a-return-type-of-our-busines/72277572?noredirect=1. There are a couple of places where one might prefer using
context(EffectScope<E>)
over
Either<E, A>
and that would be to unluck
tailrec
for example in the attached code. You can also find it here in the example project, https://github.com/nomisRev/ktor-arrow-example/pull/35/files#diff-776f1016c7b6c2c2bd6b1ba00b5a0a0ec321e140dc519e0941014bb6f39e599e
I am sure we're not finished discovering context receivers, and that is probably both in use-cases and downsides. They're very powerful.
The first one is stack-safe due to
tailrec
, but the second one is not.
s
Wow super nice when it unlocks such new possibilities, like enabling tailrec for such a use case.
I am sure we’re not finished discovering context receivers, and that is probably both in use-cases and downsides. They’re very powerful.
Absolutely! Super eager to see what else people come up with and what ends up being not that good after-all 😅