Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 18:49
    SethTisue commented #1432
  • 18:48

    SethTisue on 2.13.x

    remove JDK 16 workarounds that … (compare)

  • 18:45
    SethTisue commented #1432
  • 18:40

    SethTisue on 2.13.x

    update JDK 17 expected-to-fail … (compare)

  • 18:39
    SethTisue commented #1432
  • 18:36
    SethTisue commented #9676
  • 18:36
    SethTisue commented #9676
  • 18:36
    SethTisue commented #9676
  • 17:46
    SethTisue edited #1432
  • 17:46
    SethTisue commented #1432
  • 17:46
    SethTisue commented #1432
  • 17:44
    SethTisue edited #1436
  • 15:01
    SethTisue edited #1432
  • 15:01
    SethTisue edited #1436
  • 14:54
    SethTisue commented #12419
  • 14:53
    SethTisue labeled #9675
  • 14:46
    SethTisue edited #1436
  • 14:46
    SethTisue edited #1436
  • 14:45
    SethTisue labeled #1436
  • 14:45
    SethTisue assigned #1436
Raphael Bosshard
@esarbe
The type information is lost at runtime?
Or more like; there's no information to infer the A type when calling request?
Rob Norris
@tpolecat
Scala just isn't very good at keeping track of refinements. It can do GADTs slightly better.
It should work.
Raphael Bosshard
@esarbe
How would that look with Aux?
Hanns Holger Rutz
@Sciss
@esarbe Aux is just a type alias (see the fiddle link)
Raphael Bosshard
@esarbe
I see..
moritz bust
@busti
When pattern matching, does a type have to be sealed to satisfy exhaustiveness?
nafg
@nafg
yes
Derya Aydede
@Derya
the compiler will let you have "inexhaustive" matchings, though
moritz bust
@busti
Okay, that is unfortunate.
Joe Pallas
@jpallas
Which part is unfortunate: that inexhaustive matching is possible, or that exhaustive matching requires sealing?
moritz bust
@busti
Well, unfortunate probably is the wrong word to use generally, exhaustiveness wouldn't make much sense otherwise. It is just unfortunate because I now have to reconsider some design decisions.
Derya Aydede
@Derya
i don't see why there couldn't be an opt-in flag to allow exhaustiveness checking on unsealed stuff
moritz bust
@busti
It is always possible to use PartialFunction, but I like the compiler warnings exhaustive matching gives me. Using anything other than sealed trait would probably be too expensive.
Rob Norris
@tpolecat
This hasn't been merged into Lightbend Scala but it might if someone were to pick it back and up and shepherd it through.
I don't know what dotty does in these cases.
Joe Pallas
@jpallas
So long as people understand that exhaustiveness checking for unsealed types doesn't perform magic, it just insists that there be a default case.
vijendra singh
@viju0731_twitter
How do get hash string from string using SHA512
vijendra singh
@viju0731_twitter
Thanks i created the sha512 function in scala
vijendra singh
@viju0731_twitter
in digesUtil all hash libs are available
Dominic Egger
@GrafBlutwurst
apache commons codec? yeah thats a wrapper around javas MessageDigest it makes it a bit nicer to work with
phip123
@phip123
Can anyone explain to me, when I should use type From = String or a value class like class From(val from: String) extends AnyVal?
Dominic Egger
@GrafBlutwurst

so the latter can be very useful to avoid some annoying bugs. e.g.

val userAccountMap: Map[Int,Int]

final case class UserID(id:Int) extends AnyVal
final case class AccountID(id:Int) extends AnyVal

val userAccountMap2: Map[UserID, AccountId]

makes sure you don't mix up the two

the former type alias can be sometimes useful just for readability From might be more telling than String but it's easy to overdo and sometimes a bit of a pain when debugging. types can shine when you need to do e.g. partial application type StringKeyMap[A] = Map[String, A] for some T[_] constraint.
Dominic Egger
@GrafBlutwurst
there's more you can do with both but just for example purposes
phip123
@phip123

Thanks! If it's okay for you, I would like to have your opinion on my approach to model an Email. :)

  final case class Domain(domain: String) extends AnyVal
  final case class Name(name: String) extends AnyVal
  final case class User(name: Name, domain: Domain)
  final case class Data(data: String) extends AnyVal
  final case class Subject(subject: String) extends AnyVal
  type Users = List[User]

  final case class Email(from: User = User(Name(""),Domain("")),
                         to: Users = List(),
                         data: Data = Data(""),
                         subject: Subject = Subject(""))

Is type Users = List[User] reasonable/justified or unnecessary?

Fabio Labella
@SystemFw
@phip123 I would avoid it
type synonyms in general are in my opinion a false help: they look useful, they end up being harmful
either use a class (if you have some invariants to enforce), or just the plain List
phip123
@phip123
ok, thanks!
Shivam Panjeta
@shivampanjeta
Regex query
12,34,56,78 to 123456.78
12.34.56,78 to 123456.78
12,34,56.78 to 123456.78
basically I want to handle different currencies to double, without knowing the user's locale
sheryl11
@sheryl11
image.png
image.png
Shivam Panjeta
@shivampanjeta
p.replaceAll("[,.](?=[0-9]+[,.])", "").replaceAll(",", ".");
does this thing look fine to you guys for my use case?
Luciano
@lJoublanc
@shivam-panjeta have you looked at whether Pattern has conversions that can do this for you automatically?
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