IOApp.ResourceApp #1958
IOApp.ResourceApp #1958
Conversation
|
Might have to undo the |
|
Another path we can take here is to create a |
|
Assuming IO is still baked in, I would not call it just |
|
|
||
| trait ResourceApp extends IOApp { | ||
| def runResource(args: List[String]): Resource[IO, ExitCode] | ||
| final def run(args: List[String]): IO[ExitCode] = runResource(args).use(IO.pure(_)) |
There was a problem hiding this comment.
It feels weird doing use(IO.pure(_)) when it's usually the antipattern of using Resource.
What's the usecase for this? Most of what I've seen is doing a Resource[IO, Anything] and .useForever, as is usually the case for HTTP servers.
There was a problem hiding this comment.
Yeah I almost always do useForever with Resource-based IOApps. I think that would be the more useful default
|
IMO let's just do |
|
I've actually written several applications recently that didn't call Perhaps we can expose that as another pair of traits: |
| final def run(args: List[String]): Resource[IO, ExitCode] = run.as(ExitCode.Success) | ||
| } | ||
|
|
||
| trait Forever { self => |
There was a problem hiding this comment.
I don't really think it makes sense to have an ExitCode here... does it? also, you'll notice it doesn't extend ResourceApp for that reason, but also because we can't override main since it's declared final for now
|
|
||
| ioApp.main(args) | ||
| } | ||
| } |
There was a problem hiding this comment.
Does a ForeverSimple or Forever.Simple seem useful? It just wouldn't take any args but not sure how appealing that is if Forever doesn't need to return an ExitCode to begin with
There was a problem hiding this comment.
I guess, if even just for consistency with the other ones. I would certainly use it, since we usually take arguments from env vars.
|
Nice work! I like this addition quite a lot |
Two convenience traits that fully realize the notion that applications are resources. The two variants mirror
IOAppandIOApp.Simple--IOApp.ResourceAppandIOApp.SimpleResourceApprespectively. I could use some help with naming;IOApp.Resourceis somewhat troublesome because it overloadskernel.Resourcein scope. We could define it with the fully qualified package names though.I also took the opportunity to split out an
IOAppPlatformsince the shared code is growing a bit