Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 30 2020 23:29
    dspasojevic opened #52
  • Oct 22 2020 19:56
    marko-asplund commented #44
  • Oct 22 2020 19:48
    marko-asplund commented #46
  • Oct 22 2020 10:59
    vil1 opened #51
  • Oct 22 2020 10:58
    vil1 edited #50
  • Oct 22 2020 10:58
    vil1 opened #50
  • Oct 22 2020 10:58
    vil1 labeled #50
  • Oct 22 2020 10:16
    vil1 commented #44
  • Oct 22 2020 10:15
    vil1 closed #46
  • Oct 22 2020 10:13

    vil1 on master

    Update README.md (compare)

  • Oct 21 2020 22:14
    vil1 commented #46
  • Oct 21 2020 21:52

    vil1 on v2.2.1

    (compare)

  • Oct 21 2020 21:25

    vil1 on master

    Fix cross-building definition a… (compare)

  • Oct 21 2020 21:25
    vil1 closed #49
  • Oct 21 2020 21:25
    vil1 opened #49
  • Oct 21 2020 21:25

    vil1 on cross-build

    Fix cross-building definition a… (compare)

  • Oct 21 2020 21:21

    vil1 on sbt-ci-release

    (compare)

  • Oct 21 2020 21:21

    vil1 on sbt-ci-release

    Setup sbt-ci-release Fix build.sbt compilation Fix tests compilation (warning) and 1 more (compare)

  • Oct 21 2020 21:21

    vil1 on sbt-ci-release

    (compare)

  • Oct 21 2020 21:17

    vil1 on sbt-ci-release

    Fix cross-building definition a… (compare)

Valentin Kasas
@vil1
Well, not exactly
Valentin Kasas
@vil1
What I have in mind is rather : we implement Step[A] which is a FilterMonadic (with map, flatMap and filter methods) and method/implicit classes to lift the standard scala types into a Step (there's only a handful of such sensible types, Future, Either, Option, etc...)
This will of course require a little extra work (we wouldn't use the monad transformer machinery) but this way, we would remove the adherence to scalaz
and in separate "add-on" modules, we provide methods/implicit class to lift scalaz and cats sensible types into a Step(resp \/ and Xor)
Valentin Kasas
@vil1
That's just a suggestion though, I have no idea how it would be done exactly
David R. Bild
@drbild
I see.
I like that in the current version I can transition between Step[A] and EitherT[Future, Result, A] seamlessly. I'd hate to lose that, but we could just provide to toStep and toEitherT (toXorT) and enrichment methods in the scalaz (cats) module. That makes switching almost as easy.
David R. Bild
@drbild
I also like the current type alias approach because it makes understanding Step trivial when new to the library (assuming you already know the common monads/transformers).
But a custom Step, as you're suggesting, may be direct enough in implementation (compared to the hackery needed to support both Step = Either and Step = XorT) that it might be easiest-to-understand approach moving forward.
Valentin Kasas
@vil1
and we could also provide relevant instances for scalaz.Monad[Step] and cats.data.Monad[Step]
Valentin Kasas
@vil1
I'll give it a try and see what it looks like
David R. Bild
@drbild
sounds good
Valentin Kasas
@vil1
well, this Kanaka-io/play-monadic-actions#16 thing bothers me a lot
it feels very sad to have two operators for passing different forms of B => Result
Valentin Kasas
@vil1
so, about the 2.0 stuff
I have a (pretty simple) implementation of Step with no reference to scalaz
It compiles fine (but there is some ExecutionContext boilerplate I'll probably get rid of later
Now I have to make the test pass again ^^
Valentin Kasas
@vil1
done, please take a look at Kanaka-io/play-monadic-actions@8432acf and tell me what you think
Valentin Kasas
@vil1
See also #17 and #18
David R. Bild
@drbild
Awesome; I'll take a look this evening.
Valentin Kasas
@vil1
Ok, so it seems that our Step monad is lawful
(well, unless the underlying Future fails)
Valentin Kasas
@vil1
So, I've pushed a resolution for #17 (scalaz compat) on branch https://github.com/Kanaka-io/play-monadic-actions/tree/2.0 and published a 2.0.0-SNAPSHOT on maven central
Valentin Kasas
@vil1
and now there's a resolution for #18
(and a fresher snapshot on central)
Valentin Kasas
@vil1
but we're not done yet
Valentin Kasas
@vil1
I'm pretty sure naming the relevant packages scalaz and cats was a mistake
and there's probably a way to have less ExecutionContext pollution in the code
And of course, we still have to address #16 in a least possible breaking way
Oh and we'll need to revamp the docs as well
David R. Bild
@drbild
That implementation looks good to me. The packages scalaz and cats should probably be compat.scalaz and compat.cats so they aren't imported by import io.kanaka.play._
Should the main package move from controllers.ActionDSL to io.kanaka.playas well? The controllers.ActionDSL.MonadicActions import has always felt dirty to me. I'd rather import io.kanaka.play.MonadicActions.
David R. Bild
@drbild
In my latest project, I need a carrier that is not Future. For prior projects with similar constraints, I've just forked/rewritten this lib. Are you interested in trying to abstract over the base monad in version 2,?
Valentin Kasas
@vil1
Hi, sorry I lagged a bit, I was at ScalarConf last week end
Valentin Kasas
@vil1
so about the package layout, I agree we can do better. Our users should only have to extend MonadicActions to use the DSL
About having a different carrier, I feel it would be a bit tricky
It was able to strip out the dependency to scalaz in the core module precisely because I fixed the internal representation of Step[A] to Future[Either[Result, A]]
If we were to enable an arbitrary carrier for Step, we would again need monad transformers
Valentin Kasas
@vil1
What other carrier do you have in mind ? scalaz.Task ?
Valentin Kasas
@vil1
About the the package names, there is a problem with having our packages FQN end wit scalazor cats since it would not mix well with other "real" scalaz or cats imports
I'm thinking about having rather something like io.kanaka.play.scalaz.compat._ or io.kanaka.play.scalaz.mode._
David R. Bild
@drbild

Ending with scalaz and cats should be OK as long as they aren't at the same level as a wildcard import.

import io.kanaka.play._
import compat.scalaz._ // or FQed as import io.kanaka.play.compat.scalaz._

is OK.

import io.kanaka.play._
import scalaz._ // or FQed as import io.kanaka.play.scalaz._

is bad because the io.kanaka.play.scalaz masks the real scalaz.

For the carriers, I have one project with Task and one with Clump (http://getclump.io/)
David R. Bild
@drbild
withFilter on Step looks wrong. Won't that throw an exception if the predicate doesn't hold? Version 1.x treats InternalServerError as the zero for Result, returning that inside a Left.
David R. Bild
@drbild
Here's a variant of version 2 with Step[A] generalized to StepT[F[_], A]: https://github.com/drbild/play-monadic-actions/commits/generalize-base-monad
I didn't update the scalaz or cats modules, so only the tests in core will pass.
This uses Daniel Spiewak's shims to abstract over the scalaz and cats typeclasses.
I could flesh this out, if you want to further consider it. But if you're set against the additional complexity I won't spend the time.