https://kotlinlang.org logo
#functional
Title
# functional
d

dave08

02/14/2023, 12:15 PM
Just watched your video on the Ktor + Arrow example @simon.vergauwen, it was one of the clearest explanations I saw! What got me really afraid was all the complex utility functions in that project... like TestResource and the Kotest integration... I was wondering if all that could be pulled out into some libraries that could be re-used? Also, wondering why if anyways you're using interfaces (when not using context receivers), why not just use the
class Foo : IFoo
instead of
fun Foo() = object : Foo
?
🙏 1
s

simon.vergauwen

02/14/2023, 12:17 PM
like TestResource and the Kotest integration... I was wondering if all that could be pulled out into some libraries that could be re-used?
This has been extracted into the official Kotest Arrow integration library already ☺️ https://github.com/kotest/kotest-extensions-arrow
why not just use the
class Foo : IFoo
instead of
fun Foo() = object : Foo
?
I'm not advocating against
class Foo : IFoo
but I like using
fun
because I can do turn it into
suspend fun
if I have too, or return
Either
, etc in case I need to validate some configuration when creating the instance.
It also avoids the discussion of
IFoo
and
FooImpl
🤣
d

dave08

02/14/2023, 12:21 PM
Oh... maybe that example should use that library... 1) reducing complexity for new users trying to grasp how to do things, 2) serves as a bit of an example on how to use the library.... (there doesn't seem to be any docs and it's not on the list here either: https://kotest.io/docs/extensions/extensions.html)
s

simon.vergauwen

02/14/2023, 12:22 PM
Yes, I need to update my example project still. I have been busy with some other things. 2) we should definitely include it there. I offered some support for the integration library, but didn't build it myself. cc\\ @Imran/Malic
d

dave08

02/14/2023, 12:23 PM
Well it could be
fun FooImpl()..
, just as much as
class Foo
... but I have to admin I do have a tendency for `Impl`s... and functions look funny with that 😁
It's also not just Kotest, I think there might be certain helpers for Ktor there too... would that be worth a library? (or maybe surprise surprise -- there already is one somewhere 😉)
Will a typical end-user be forced to write such helpers in daily use? If so, maybe it could be simplified? I think that kind of code could scare off new users 🤒...
I think that's why Ktor 2 made a DSL out of their plugins... it was just too much boilerplate -- you don't see what the plugin is doing...
s

simon.vergauwen

02/14/2023, 12:31 PM
What helpers are you referring to? 🤔 There is only 1 helper, and it's indeed already a library 😂 https://github.com/arrow-kt/suspendapp#suspendapp-with-ktor I am talking about this a bit on Thursday, https://info.jetbrains.com/kotlin-webinar-february16-2023.html?utm_campaign=webinar-february16-2023 In the video I mention some things relying on context receivers, which are not stably released until Kotlin 2.0.
We're working on a new documentation website, where we'll reference these things in a more clear way in an organised manner that you can find all this information in the same place. Together with removing all deprecated methods we discussed yesterday this'll make Arrow 2.0 ☺️ ETA end of Q1
d

dave08

02/14/2023, 12:34 PM
Little suggestion for the new docs... maybe a little table with features supported per version, deprecations, and recommended replacements? It would give a birds-eye view on what can be used with each version and what's involved in upgrading, etc...
s

simon.vergauwen

02/14/2023, 12:37 PM
We're going to provide that for the 1.2.x release, since almost all of the changes can be scripted. It mostly involves replacing some imports, or invoking automatic refactoring from IDEA (
ReplaceWith
/
alt+enter
). Only some very obscure APIs will not be able to be automated, but we've added in the deprecation method to please contact us if you heavily rely on them. But we'll be sure to also reference it on the new website 😉 Thanks for the suggestion ☺️
If you're not using any
@Deprecated
methods in
1.x.x
it's extremely unlikely you won't be able to fully automatically migrate to 1.2.x and be source-compatible with 2.x.x.
d

dave08

02/14/2023, 12:46 PM
(not that I understand what it does apart from provide some resources using property delegation... it's chinese for me...)
s

simon.vergauwen

02/14/2023, 12:48 PM
https://github.com/kotest/kotest-extensions-arrow/blob/5e3d45b977f53d52692fb4dade9[…]lin/io/kotest/assertions/arrow/fx/coroutines/ProjectResource.kt https://github.com/kotest/kotest-extensions-arrow/blob/5e3d45b977f53d52692fb4dade9[…]n/io/kotest/assertions/arrow/fx/coroutines/ResourceExtension.kt The API is slightly improved to what is in the repo, and the KDoc offers minimal documentation. I noticed that
val conn: TestResource<Connection> =
is incorrect though in the KDoc, it should probably be
LazyMountableExtension
🤔
d

dave08

02/14/2023, 12:52 PM
Oh... that was hidden in assertions fx... maybe there could be an indication of basic use in the Readme...? Especially finding those basic classes...
Because of the name I assumed they were all assertions...
s

simon.vergauwen

02/14/2023, 12:52 PM
Could you open an issue on the repo to track this please? 🙏
Please provide all feedback you have, so it doesn't get lost into this Slack thread.
s

simon.vergauwen

02/14/2023, 12:59 PM
Awesome, thank you 🙌
d

dave08

02/14/2023, 1:00 PM
But no mention of those above classes, since they're in the assertion modules
s

simon.vergauwen

02/14/2023, 1:01 PM
Yes, it's incomplete 😞
d

dave08

02/14/2023, 1:01 PM
An even better reason to separate them from there and add them to the extensions page...
I'd say a
io.kotest.extensions:kotest-extension-arrow:
dependency.
(I added that to the issue to clarify)
Another little docs suggestion: Summary pages such as https://arrow-kt.io/docs/fx/ could have a little description of the use of each construct... a birds-eye view avoids having to go through all the pages to find something... I usually like docs with summaries I can skim through to get a more general idea of what's available and then come back to a certain point when I think it might apply to what I'm working on.
s

simon.vergauwen

02/14/2023, 1:18 PM
I have it on my TODO list to create something like this for the new website, https://reactivex.io/documentation/operators.html#categorized A tree like overview of what to use in what scenarios, would that fit your suggestion?
d

dave08

02/14/2023, 1:27 PM
That's a page that organises by use-case... but is that going to be the navigation through the site? Were you thinking of something like: https://refactoring.guru/design-patterns/creational-patterns? Or is that just going to be a page like any other on the site, and the navigation won't have any explanations? I guess they're both fine in the end, and each have pros and cons... the nav style has info spread out in multiple pages, whereas the one-page style leaves navigation unexplained and having it be the launch point into other pages for newer users.
s

simon.vergauwen

02/14/2023, 1:29 PM
Ah, I see you mean use-cases/patterns. That will be included in the new documentation, and those documents are currently being drafted but please feel free to provide more feedback once it becomes available ☺️ Only through feedback it can be improved.
e

Emil Kantis

02/14/2023, 4:11 PM
Glad I'm not the only one using
fun Foo() = object : Foo
🙂 Is there any caveats to doing it? Is it more expensive to create an anonymous object than multiple instances of a predefined class for instance? Not really sure what happens under the hood 🙂
s

simon.vergauwen

02/14/2023, 4:19 PM
Not that I am aware of. They're still "predefined" classes from the point of view from the JVM afaik, they just get assigned a anonymous
package$bla$Foo
name at compile time.
i

Imran/Malic

02/14/2023, 7:21 PM
Hi @dave08 thanks for the issue and the input. I haven’t had much time lately to contribute on kotest Arrow, but the documentation effort was something we planed after we finished 1.3.0. I will drop you in the following PR’s regarding that
regarding the
io.kotest.extensions:kotest-extension-arrow:_
package I dont really understand the purpose of it other than grouping all api’s together but since kotest favours modularity I dont see how this applies. But I might not understand the dedicated purpose you mentioned, can you rephrase 🙂
The API is slightly improved to what is in the repo, and the KDoc offers minimal documentation. I noticed that
val conn: TestResource<Connection> =
is incorrect though in the KDoc, it should probably be
LazyMountableExtension
🤔
@simon.vergauwen good catch 😆 missed that one
d

dave08

02/15/2023, 3:55 AM
Assertions just assert on results whereas an extension is installed in the kotest lifecycle, they both have separate sections in the kotest docs and an extension is not expected to be in a module that adds assertions... That's why I couldn't find the extension at first...
27 Views