Proposal: Renaming this library

[geirolz]

Proposal: Renaming this library

[benhutchison]

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]

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]

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]

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]

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]

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