Proposal: Renaming this library

geirolz commented 9 months ago

I often talk to colleagues who use cats-core, cats-effect, etc... but know nothing about mouse. This is sad because I love mouse and all its features ( which prevents the usage of EitherT and OptionT for instance) , but I see the reasons why this can't be merged within cats-core.

However, I wonder if there is a way to improve the visibility of this project. With the arrival of Scala 3 we can take the opportunity to rename/fork this library to a better and clearer name which includes cats- as prefix to let it be more part of an ecosystem. I see cats-core as the base, mouse as an advanced syntax of cats and cats-effect as the effects system. At the moment, mouse seems an independent library and not a cats ecosystem add-on to me.

I don't want to blame the current name, I just wonder if a rebranding would improve the visibility of this library which, in my humble opinion, should be part of every cats-based project. Too many times I have seen boilerplate and operators that are already part of mouse rewritten within Utils classes.

Going deeper, the problem I see with the mouse name is that it doesn't really describe the purpose of the library, which aim to just enrich cats with a nice and useful syntax without adding new type classes or features.

Some ideas:

cats-pragmatics (polished, but I'm not sure if it is correct)
cats-mouse ( more conservative )
cats-suit / cats-dress ( fancy and funny but I don't know how explanatory it is )
cats-enrichments / cats-rich-syntax ( more serious but clear )

Something like this, for instance:

"org.typelevel" %% "cats-core" % "x.y.z",
"org.typelevel" %% "cats-rich-syntax" % "x.y.z",
"org.typelevel" %% "cats-effect" % "x.y.z",

Once done with the name, I'd also rethink the packages because it would be nice to try to keep the same pattern as cats-core in order to simplify the life of the users. Since mouse adds syntax to cats core, maybe it is correct to put it under cats.syntax package, where mouse is a specialization of the basic cats syntax. This creates a kind of boundary.

Moreover, this is also useful to better organize imports with Scalafmt

rewrite.rules = [ SortImports ]

Example

// current 
import cats.syntax.all.* // imports all cats-core syntax
import mouse.all.* // import all mouse syntax

// new
import cats.syntax.all.* // imports all cats-core syntax
import cats.syntax.rich.all.* // import all cats rich syntax

We could also consider to no having a global import but split them by type as suggested in #362 which I like TBH


import cats.syntax.collections.* // import all cats boxed syntax
import cats.syntax.nested.* // import all cats nested syntax

//or 
import cats.syntax.rich.collections.* // import all cats boxed syntax
import cats.syntax.rich.nested.* // import all cats nested syntax

To rename or not, what name and how to do it is up to you, but I just wanted to sow a seed for a discussion. Maybe I am the only one who sees this problem.

Let me know what you think :)

benhutchison commented 9 months ago

Mouse is a 10 year old, stable library. Renaming would likely be disruptive and IMO not welcomed by many/most users. The potential benefits seem intangible and may not come to be, but the costs of a rename are definite.

danicheg commented 9 months ago

A while ago there was a similar request to merge the mouse into the main cats' repository including potential renaming. From my feelings, nothing has changed since then. I'd stand for having it separate as it has been for ten years as pointed out by Ben. I struggle to say that any rebranding would make mouse famous.

benhutchison commented 9 months ago

In another direction: there's probably a subset of Mouse's syntax that's proven to be particularly commonly useful. And other methods that don't see as much use.

If we could somehow quantify what the most useful parts of Mouse's API were, I'd be supportive of migrating those into the syntax modules of Cats, so that more people can benefit from them without an extra library. It would be dependent upon the Cats maintainers agreeing of course.

@geirolz would that achieve some of what you're seeking?

satorg commented 9 months ago

Perhaps, we could consider consolidating some syntax like OptionOps and TryOps in one place – either "cats" or "mouse". Personally, I often feel a bit annoyed when I need import those syntaxes from both places. One of those syntaxes I use the most is the cata function. For types Option and Try it is implemented in "mouse" but "cats" has its own cata/cataF for OptionT for example.

On the other hand, due to the struggle we can face fighting binary/source compatibilities that idea may not be worth it...

danicheg commented 9 months ago

Yep, compatibility tax (as well as having a lot of deprecated API) makes it itty-bitty beneficial from my point of view. This might be worth the hassle only in Cats 3.0. But it's barely possible we will see it in the next N years.

geirolz commented 8 months ago

I see your points, I don't think renaming it self can make mouse famous but I think that making it easier to use improve the adoption. In any case I feel your doubts about this, totally understandable.

@benhutchison that is a good idea, I believe that everything related to F[Either[L, R]], F[Option[A]], F[Boolean], Either, Try, Option should be taken in account to be moved. Those helps transformation avoiding EitherT and OptionT that sometimes are used just for convenient syntax. I don't see those syntaxes as polished but as a basic operators to manipulate the shape. I admit that it's a bit annoying that cats doesn't have method to simply combine and lift data.

Inconsistency with Mouse:

cats has Nested -> mouse has convenient syntax to avoid lifting to and from Nested, all the *In methods
cats has EitherT and OptionT -> mouse has the syntax to lift Any, F[Any] into monad transformer
cats has Any.asRight / Any.asLeft -> mouse has Any.asRightF / Any.asLeftF*
cats has Any.some -> mouse has Any.someF*
cats has F[Boolean].ifM -> mouse has andM / orM
Try.toEither is defined in both Scala and Mouse
cats has List.toNel -> mouse has List.tailOption and List.tailOrEmpty
cats has Set.toNes -> mouse has Set.tailOption and Set.tailOrEmpty

Inconsistency with Scala:

scala has Try.toOption -> mouse has Option.toTry

I'll try to enrich the list as soon as possible.

* inconsistent between Either and Option, but this is another topic

typelevel / mouse

Proposal: Renaming this library #482