Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 15:47
    SethTisue commented #9602
  • 15:43
    bishabosha synchronize #9617
  • 15:27
    SethTisue synchronize #1238
  • 15:19
    bishabosha synchronize #9617
  • 15:19
    bishabosha edited #9617
  • 15:09
    dwijnand labeled #8932
  • 14:57
    SethTisue edited #1238
  • 14:57
    SethTisue edited #1238
  • 14:56
    SethTisue opened #1238
  • 11:47
    sjrd commented #9617
  • 11:37
    denisrosset commented #8932
  • 11:37
    denisrosset synchronize #8932
  • 10:11
    bishabosha commented #9617
  • 10:10
    bishabosha commented #9617
  • 09:50
    vincenzobaz opened #2005
  • 09:43
    denisrosset synchronize #8932
  • 09:41
    denisrosset commented #8932
  • 09:32
    denisrosset synchronize #8932
  • 09:20
    denisrosset synchronize #8932
  • 08:27
    denisrosset synchronize #8932
Abdhesh Kumar
@abdheshkumar
@sherifkandeel Try.flatMap is a abstract method and it is overridden by sub-types(Success,Failure). let say you have val t: Try[String] = Success("Hello") so when you call it t.flatMap then It will call Success.flatMap. Success.flatMap know to how to run given function which is happy path.
Fabio Labella
@SystemFw
@sherifkandeel yes, it's supposed to do that but the code is guarding against the case where this doesn't happen
Sherif Mohamed
@sherifkandeel
@abdheshkumar True, but the override implementation I copied was from Success because the case of Failure is pretty simple.
@SystemFw Makes sense. Thank you :)
Fabio Labella
@SystemFw
well, actually I need to take a look at the real code
nah, that's it I think
Luciano
@lJoublanc
@shivam-panjeta that's what I was going to suggest. you can use Locale.getDefault and it should pick up the system locale I think. See the Locale javadoc.
Abdhesh Kumar
@abdheshkumar
Every function given to try is also handled the error.
Fabio Labella
@SystemFw
iirc map for Try does the same
Sherif Mohamed
@sherifkandeel
@SystemFw No, not really, it's just:
  override def map[U](f: T => U): Try[U] = Try[U](f(value))
Abdhesh Kumar
@abdheshkumar
@sherifkandeel Try.apply handle an exception`
Fabio Labella
@SystemFw
scala> scala.util.Try(1).map(x => (throw new Exception): Int)
res1: scala.util.Try[Int] = Failure(java.lang.Exception)
Sherif Mohamed
@sherifkandeel
@abdheshkumar @SystemFw ah, yes. so you don't need to handle again, since you're already wrapping it in try
The Try in Try[U](f(value)) takes care of that
you could've done the same for flatmap, but then you would end up with Try[Try[U]]
Luciano
@lJoublanc

Guys I have a question about implicit resolution. The resolution rules look by default in the companion of any types that are in the signature. So e.g. for (implicit fa: F[A]) it will check both the companion of F[_] and A and their related classes etc.
However, if I'm unable to extend these (e.g. shapeless.Typeable == F[_] and fs2.Chunk == A, both from external libraries), then I have to resort to explicitly importing the instances. Is there any way around this, to avoid the explicit import?
For a concrete example:

trait MyTypeclass[...] {
}

object MyTypeclass {
  implicit def typeableInstance[A]: Typeable[Chunk[A]] = ???
  implicit def myTcInstance(implicit: Typeable[Chunk[_]]): MyTypeclass = ???
}

When I want to use my typeclass in the above example, I always need to do

import MyTypeclass._
implicitly[MyTypeclass]

And if the library user doesn't know they need the first import statement. Really annoying. How can I work around this?

Fabio Labella
@SystemFw
right, you have an orphan instance, which generally requires an import
there might be a way to work around it, let me give it a shot
Fabio Labella
@SystemFw
object Lib1 {
  type Foo
}
object Lib2 {
  trait Name[A] { def name: String }
}

object Repro {
  trait UpperName[A] {
    def name: String
  }
  object UpperName {
    implicit def orphan[A]: Lib2.Name[Lib1.Foo] = new Lib2.Name[Lib1.Foo] {
      def name = "foo"
    }
    implicit def myTcInstance(
        implicit ev: Lib2.Name[Lib1.Foo]): UpperName[Lib1.Foo] =
      new UpperName[Lib1.Foo] { def name = ev.name.toUpperCase }
  }

  object Imports {
    import UpperName._
    val res = implicitly[UpperName[Lib1.Foo]].name // FOO

  }
  // Doesn't compile
  // object NoImports {
  //   val res = implicitly[UpperName[Lib1.Foo]].name
  // }
}

object Fix {
  trait UpperName[A] {
    def name: String
  }
  object UpperName {
    trait Carrier[TC[_], A] {
      def evidence: TC[A]
    }
    object Carrier {
      implicit def forNameFoo: Carrier[Lib2.Name, Lib1.Foo] = new Carrier[Lib2.Name, Lib1.Foo] {
        def evidence = orphan
      }
    }
    def orphan[A]: Lib2.Name[Lib1.Foo] = new Lib2.Name[Lib1.Foo] {
      def name = "foo"
    }

    implicit def myTcInstance(
        implicit ev: Carrier[Lib2.Name, Lib1.Foo]): UpperName[Lib1.Foo] =
      new UpperName[Lib1.Foo] { def name = ev.evidence.name.toUpperCase }
  }

  object NoImports {
    val res = implicitly[UpperName[Lib1.Foo]].name // FOO
  }
}
@lJoublanc there you go
you can simplify the solution a bit
i.e. with this solution you can move Carrier outside of the companion of UpperName, but if you don't need to do that then forNameFoo can be outside of the Carrier companion (which can be eliminated). orphan can be inlined as well, should you wish to do so
Luciano
@lJoublanc
Hi @SystemFw , as always, big thanks for taking the time to help out. So if I understand the trick here is to have a 'wrapper' (Carrier) that just holds the instance I need. And because it's in implicit scope of UpperName (MyTypeclass in my example), it will be picked up. Is that about right?
Fabio Labella
@SystemFw
not quite
Luciano
@lJoublanc
?
Fabio Labella
@SystemFw
the trick is that MyTypeclass now depends on Carrier, so the search includes the implicit scope of Carrier
Luciano
@lJoublanc

Right, so

And because it's in implicit scope of UpperName (MyTypeclass in my example), it will be picked up

is not correct

Fabio Labella
@SystemFw
nope
because your original code is also in the object
the reason why you can eliminate the companion of Carrier is because the object in which a TC is defined is also part of the scope of that TC
Luciano
@lJoublanc
Ok, got you. But the jist is that wrapping the typeclasses in a new type means that the implicit search changes from the companion of the original dependency to this new dependency.
Fabio Labella
@SystemFw
but if you move Carrier outside of UpperName's companion, then the instance needs to be in the companion of Carrier
@lJoublanc yes
Luciano
@lJoublanc
Ah, right, so I can remove object Carrier as long as I keep the instance in UpperName. I undestand now.
Fabio Labella
@SystemFw
it's the "complementary" trick to newtyping Chunk
I'm newtyping the typeclass
since I figure you most likely want to expose Chunk to the user as is
whereas Typeable is an implementation detail

Ah, right, so I can remove object Carrier as long as I keep the instance in UpperName. I undestand now.

:+1:

Luciano
@lJoublanc
Thanks for the help again. :)
Fabio Labella
@SystemFw
no problem :)
etienne
@crakjie
Is there some documentation about session management in functional programing lanaguage? ( database sessions )
Gavin Bisesi
@Daenyth
@crakjie doobie would be a great thing to look at design-wise
etienne
@crakjie
@Daenyth i'm reading that now http://tpolecat.github.io/presentations/doobie1.html#6 so I'm not far away from doobie source code ;)
Gavin Bisesi
@Daenyth
tldr; it defines a free monad that is conceptually wrapping JdbcConnection => A
Alwin
@alwins0n
hey guys, can I ask a newbie question?
Gavin Bisesi
@Daenyth
and then it has a Transactor[F: Effect] which wraps the thread pool and gives you transact: ConnectionIO ~> F
@alwins0n yup!
Alwin
@alwins0n
alright - i dont get y the following wont compile (imcopatible types)
Gavin Bisesi
@Daenyth
scalafiddle/scastie are quite helpful in fixing those btw
if you can put your example code there