EffeKt implementation details

[bendgk]

This discussion was started as a way to talk about ideas about the implementation details of EffeKt.

Originally this was a discussion on reddit between u/bendgk and u/n0tkamui but it is now open to the floor.

[bendgk]

The current conversation so far:

bendgk:
Hey, I think we should either dm or discuss this on GitHub

you last mentioned "ScopedRef shouldn't be delegated a scope. the ref is scoped, it's not a scope itself."
I probably agree with that statement, but I'm just wondering what the difference is both Semantically and Technically

n0tkamui:
i don't think it's a good idea to hide this discussion from the main thread... but anyway

it's not just a semantic difference. do you you what implementation by delegation does?

in your code, ScopedRef IS a CoroutineScope, meaning it has EVERY methods a CoroutineScope has.

that should be the case, it's not its responsibility at all.

realize that you even do something as abberant as this with the way you did things

coroutineScope {
val a = ref(0)
launch(a) { // this is abberant
...
}
}

you can even write

val b = a.ref(1)
which is even dumber
moreover, you still have a global mutable state, and completely ignored two of my propositions/questions :

• will you publish this on Maven Central?
• why don't you add a way create a effect scope so that your global state doesn't leak around AND so that the coroutine scope actually serves a purpose (because it does nothing useful at the moment)

in your code, ScopedRef IS a CoroutineScope, meaning it has EVERY methods a CoroutineScope has.
that should not be the case, it's not its responsibility at all.

bendgk:
Hi,

I'll respond to each message one by one
But first, If you don't want to hide the discussion then let us move it to GitHub. I strongly feel Reddit is not the correct place for discussion of the Implementation details of EffeKt.

[bendgk]

Yeah, I agree, ScopedRef should not extend CoroutineScope that was a brain-fart moment lol.

Hmm ill play around with an effektScope maybe, but I don't really want to introduce another type of scope when kotlin has CoroutineScope already

If by the global mutable state, you're talking about the lock and activeEffect that stuff is private and isn't exposed so it should be fine. you also mention that the global state is "leaking around" but I don't quite get what you mean by that, care to elaborate?

I would like to publish this to maven central, but this is actually my first time publishing to maven central and it seems somewhat involved with all of their requirements, so I'm still reading up on how to do that (I'm confused if I need a pom.xml to publish to maven central).

Currently, I've published to jitpack using github tags, the most recent one 1.0.1 should be commit 2efd8135d1

[notKamui]

I am talking about memory management. Since global state in Kotlin are put in singletons, this means that as soon as someone uses your library, for the entirety of the lifetime of the application, with no other choice, and in a non transparent way, you have allocated memory that will never be freed.

I don't see why the existence of coroutine scopes is an issue that restrains you to add effect scopes.

Scopes solve several problems while offering future flexibility.

• when you're out of scope and no one is referring to your scope, everything will be freed. This becomes a conscious choice instead of a forced one.
• you can bind a single coroutine scope to all the primitives inside said scope very easily, instead of giving the effects themselves scopes : that is not their responsibility and is what leads you to duplication. check out inversion of dependancies
• if you check most libraries that deal with contexts, that's exactly what is either strictly done, or at least semantically done : @Composable with Jetpack Compose, setup functions for composables in Vue (same with hooks and React), @Transactional in the JPA specifications, withTransaction in Exposed ; i could go on forever since it's so common of a pattern.
• it's way easier to achieve thread safety, because you localize what needs to be linked to each other things, instead of locking your whole application
• having a localized coroutine scope will allow you to use a proper Mutex instead of a ReantrantLock which blocks the thread instead of suspending it. Global locks are inherently bad if avoidable, private or not.

I would still recommend you publish it to Maven Central eventually. People don't want to add repositories to their Gradle file for only one package, everyone is lazy. Moreover, it adds credibility to your package. This is for publicity sake.

I know you're probably testing things out, but eventually you'll have to need to merge your two packages or force the utilisation of coroutines (which isn't a bad idea imo, since we're talking about effects). The high semantical coupling of non technically coupled APIs will hurt your development in the long term.

You need a pom yes, but Gradle allows you to make one really easily within your build file. You can check out my libs if you want, for reference (Keval for example)

[notKamui]

also, do follow semantic versioning

your library is still in alpha (or at least should be)

so your major version should still be under 0.y.z and postfixed with -alpha

so, something like 0.4.0-alpha

in semantic versioning, for x.y.z ,

• x is major version and is increased when you do breaking changes, or upped from 0 to 1 when you leave beta. when it's 0 (beta), you can still do breaking changes but should limit them.
• y is minor version and is increased everytime you have a new feature
• z is patch version and is increased everytime you have a bug
• you reset y and z to 0 when x++, and z to 0 when y++

[notKamui]

Finally, do not expose abstract classes if they're not meant to be extended : use interfaces. ScopedRef should not be public