Add AutoDisposeContext + withScope functions

[ZacSweers]

This allows for some more idiomatic kotlin usage like so:

withScope(sourceScope) {
  someObservable.autoDispose().subscribe()
}

[ShaishavGandhi]

I wish there was a way to let go of the autoDispose() and then it would read exactly like Flow but alas.

[ShaishavGandhi]

I guess you want with or under? i.e
Executes a [body] under an ....
or
Executes a [body] with an...

[ZacSweers]

32e7e08

[ShaishavGandhi]

Given that this is in the autodispose module and that you can use it with a normal ScopeProvider as well, we can probably skip the reference to coroutines.

[ZacSweers]

That's a stale doc from the original PR, will fix

[ZacSweers]

b2dbd58

[ShaishavGandhi]

How about adding convenience functions like:

fun withScope(coroutineScope: CoroutineScope, body: AutoDisposeContext.() -> Unit) {
  withScope(coroutineScope.toScopeProvider(), body)
}

in the coroutine-interop module?

Can do in a followup if you want.

[ZacSweers]

How about adding convenience functions

I don't like it in this case tbh. I think convenience functions make sense for discoverability and shorthands for common cases, but that case isn't either of those.

[ShaishavGandhi]

Given that withScope is so similar to withContext from coroutines, it'd be perplexing to not overload withScope with a CoroutineScope since coroutines users will have an instinct of using the with* functions. Just my 2 cents.

[ZacSweers]

withContext is not a scoping construct like this is though, whereas this is a scoping construct and not doing anything implicitly with the block passed in other than affording it extra APIs. withContext will execute your block on a different context. I thought about calling this AutoDisposeScope at first, but context in this case in reference to the context that those extension functions are available.

It's best not to think of this as having anything to do with coroutines or coroutine scope because it's unrelated functionality. The only thing in common really is that they use higher order functions with receivers :)

[ZacSweers]

Also - I think a good API boundary here is supporting AutoDispose's core types, and anything else that can be interop'd back to them should just use that. Otherwise it's a slippery slop to supporting anything that Completable and ScopeProvider can interop out to: CoroutineScope, LifecycleProvider (2 and 3), etc. If someone wants to write their own extension function to get the API you're describing, great! But otherwise I feel pretty strongly about keeping the API surface area here down to just AutoDispose's own core components.

[ShaishavGandhi]

Also - I think a good API boundary here is supporting AutoDispose's core types, and anything else that can be interop'd back to them should just use that.

Yeah I strongly agree with that. Given the nature of composability of Rx, we'd end up supporting lots of overloads.

The little inkling was mainly because of the similarity in names but it's only a minor inconvenience for people to just do .asScopeProvider()