-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider moving Unapply
out of cats
#1607
Comments
There was a pre-SI-2712 fix issue similar to this: #574. I think that it's largely irrelevant now, though. FWIW, I'm 👍 on removing |
Once I get TwoTails to a point, I will happily remove Unapply from AutoLifts. Just not enough free time to prioritize. |
I think it would be good to remove it before Cats 1.0. |
How about we move this to kittens? @milessabin |
Haven't we just removed unapply from Kittens though? |
@milessabin yes we did. I am not sure if kittens is the right place for it either. I think the |
What about cats-unapply with no dependency on cats but in the same package
name. Current users just add a dep to cats-unapply and no other change.
Probably the code never needs to change and we can delete it sometime later
if we really want to, but keeping it around probably does no harm.
…On Mon, Apr 24, 2017 at 05:37 Kai(luo) Wang ***@***.***> wrote:
@milessabin <https://github.com/milessabin> yes we did. I am not sure if
kittens is the right place for it either. I think the Unapply machinery
could be helpful for scenarios where the left-to-right partial unification
doesn't apply, but I don't know where it should go either. Maybe everyone
just copy it to their own project since the usage will be so limited?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1607 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEJdtMqNRqvDkjCInssLXc0CV9nvzRrks5rzMGfgaJpZM4M_Ouh>
.
|
@johnynek I could get behind a micro-library that just provides |
@ceedubs that's a good point. Another thing that we could move to this micro library would be the |
See that's why I wouldn't do it. If others are using Unapply adding
cats-unapply is no big pain, and easy for us to do. If it becomes a bunch
of work it defeats the purpose for everyone involved (type renaming in any
files, for instance).
If we don't want a submodule for reasons, my second argument would be just
keep it but don't use it.
My third vote is just delete it.
…On Fri, Apr 28, 2017 at 03:56 Kai(luo) Wang ***@***.***> wrote:
@ceedubs <https://github.com/ceedubs> that's a good point. Another thing
that we could move to this micro library would be the Trivial class
removed in this PR #1621 <#1621>.
If we decide to create a new repo for them, shall we create it directly
under typelevel github org, or shall we create under another account and go
through the incubation process?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1607 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEJdmLtscA1fCFijjezXXschlldl2b1ks5r0fAVgaJpZM4M_Ouh>
.
|
@kailuowang kittens already has |
After #1583, cats no longer uses the
Unapply
machinery to overcome SI-2712.There are other projects using it, e.g. @wheaties's AutoLifts and my henkan We should consider moving
Unapply
to a separate project since it's no longer needed by cats and it is not a cohesive part of the what cats' offering, i.e. lib for pure functional programming.The text was updated successfully, but these errors were encountered: