Move cats-free and cats-state in to cats-core? #760
Comments
|
👍. I think modularity is a good goal, but I don't think this is a useful way to cut things. Together these two jars are less than 5% of the size of cats core, and I don't think separating them makes the API more intelligible in any way. |
|
👍 |
|
Hooray! |
|
👍 |
|
Can be closed now that #765 is merged. |
ceedubs
added a commit
to ceedubs/cats
that referenced
this issue
Apr 23, 2016
It's quite possible that people are going to throw tomatoes at me for proposing this change. There has been much discussion about modularization in the past, and in fact free used to have its own module, which was removed in typelevel#760/typelevel#765. One significant change that has happened since then is that `State` has started to use `Eval` instead of `Trampoline` for trampolining. At this point, nothing outside of the `free` package in `cats-core` depends on `free` (which is why this PR was so easy to create). To me that makes it a fairly convenient border for modularization. There was a [brief discussion](https://gitter.im/typelevel/cats?at=5716322b548df1be102e3f3c) about this on Gitter in which @sellout supported this change on the basis that they prefer to use fixpoint types (such as `Mu`) for free structures. Putting `free` into a separate module may be better for people who want to use different variations of these structures. Of course in addition to these more recent updates, there are the usual arguments for modularization and decreased jar size (which I believe is especially important for `catsJS` users).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I don't recall the rationale for making the
cats.freepackage its own module, but the way in which it forcesStateto be in its own module is a big enough of a disadvantage that I think we should reconsider.This would also allow us to close https://github.com/non/cats/issues/573.
The text was updated successfully, but these errors were encountered: