Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 19:47
    eed3si9n edited #8591
  • 19:28

    SethTisue on 2.13.x

    2.12: new Scala SHA 2.12: update expected-failure l… add akka-http-webgoat (#1017) and 1 more (compare)

  • 19:08

    SethTisue on 2.11.x

    sbt version bump (1.3.3->1.3.4)… 2.12: new Scala SHA 2.12: update expected-failure l… and 3 more (compare)

  • 19:04
    SethTisue commented #8545
  • 19:03
    som-snytt commented #11824
  • 18:54
    som-snytt labeled #11824
  • 18:54
    som-snytt commented #11824
  • 18:46
    som-snytt review_requested #8591
  • 18:46
    scala-jenkins milestoned #8591
  • 18:46
    som-snytt opened #8591
  • 18:38
    SethTisue milestoned #3237
  • 18:38
    SethTisue assigned #9386
  • 18:38
    SethTisue milestoned #9386
  • 15:21
    som-snytt commented #8590
  • 14:50
    lrytz commented #8588
  • 13:12

    lrytz on 2.13.x

    Avoid length of list Lint confusing by-name conversi… Lint by-name conversion of bloc… and 1 more (compare)

  • 13:12
    lrytz closed #8590
  • 13:12
    lrytz closed #9386
  • 13:12
    lrytz closed #3237
  • 09:36
    dwijnand commented #1016
Luciano
@lJoublanc
I recall it had some special handling of locales.
Shivam Panjeta
@shivampanjeta
But I don't know the locale
Luciano
@lJoublanc
But the system does..
Shivam Panjeta
@shivampanjeta
NumberFormat format = NumberFormat.getInstance(Locale.FRANCE);
Number number = format.parse("1,234");
double d = number.doubleValue();
say this
but I don't want to take locale into account
Sherif Mohamed
@sherifkandeel

Could someone explain to me how flatmap in Try works? in case of success, this is how you apply flatmap

override def flatMap[U](f: T => Try[U]): Try[U] =
    try f(value) catch { case NonFatal(e) => Failure(e) }

But it doesn't make sense to me, because f(value) returns Try[U] which will never throw exception, why there's catch?

Fabio Labella
@SystemFw
@sherifkandeel it also guards against the case where f throws an exception before returning Try
Sherif Mohamed
@sherifkandeel
@SystemFw that is what confuses me. f is supposed to encode the exceptions in the Try that's the whole point of returning a Try so I was skeptical it's just an extra safeguard
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 )