Just watched your video on the Ktor + Arrow exampl...

# functional

[dave08]

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?

[simon.vergauwen]

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.

[simon.vergauwen]

It also avoids the discussion of IFoo and FooImpl 🤣

[dave08]

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)

[simon.vergauwen]

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

[dave08]

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 😁

[dave08]

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 😉)

[dave08]

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 🤒...

[dave08]

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...

[simon.vergauwen]

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.

[simon.vergauwen]

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

[dave08]

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...

[simon.vergauwen]

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 ☺️

[simon.vergauwen]

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.

[dave08]

It doesn't look like this is in the Kotest library: https://github.com/nomisRev/ktor-arrow-example/blob/main/src/test/kotlin/io/github/nomisrev/TestResource.kt

[dave08]

(not that I understand what it does apart from provide some resources using property delegation... it's chinese for me...)

[simon.vergauwen]

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 🤔

[dave08]

Oh... that was hidden in assertions fx... maybe there could be an indication of basic use in the Readme...? Especially finding those basic classes...

[dave08]

Because of the name I assumed they were all assertions...

[simon.vergauwen]

Could you open an issue on the repo to track this please? 🙏

[simon.vergauwen]

Please provide all feedback you have, so it doesn't get lost into this Slack thread.

[dave08]

https://github.com/kotest/kotest-extensions-arrow/issues/229

[simon.vergauwen]

Awesome, thank you 🙌

[dave08]

Actually I just saw this: https://kotest.io/docs/assertions/arrow.html

[dave08]

But no mention of those above classes, since they're in the assertion modules

[simon.vergauwen]

Yes, it's incomplete 😞

[dave08]

An even better reason to separate them from there and add them to the extensions page...

[dave08]

I'd say a io.kotest.extensions:kotest-extension-arrow: dependency.

[dave08]

(I added that to the issue to clarify)

[dave08]

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.

[simon.vergauwen]

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?

[dave08]

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.

[simon.vergauwen]

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.

[Emil Kantis]

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 🙂

[simon.vergauwen]

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.

[Imran/Malic]

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

[Imran/Malic]

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 🙂

[Imran/Malic]

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

[dave08]

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...