Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jun 22 23:31
    retronym commented #12419
  • Jun 22 23:31
    smarter commented #12419
  • Jun 22 23:29

    SethTisue on 2.12.x

    2.12: new Scala SHA (#1436) (compare)

  • Jun 22 23:29
    SethTisue closed #1436
  • Jun 22 23:26
    retronym commented #12419
  • Jun 22 22:04
    SethTisue synchronize #1436
  • Jun 22 22:01
    deanwampler commented #1252
  • Jun 22 22:00
    deanwampler-domino commented #1253
  • Jun 22 21:55
    SethTisue commented #1252
  • Jun 22 21:55
    SethTisue edited #1253
  • Jun 22 21:55
    SethTisue opened #1253
  • Jun 22 21:53
    SethTisue commented #1252
  • Jun 22 21:52
    SethTisue closed #1252
  • Jun 22 21:46
    SethTisue synchronize #1436
  • Jun 22 21:39
    deanwampler opened #1252
  • Jun 22 21:37
    deanwampler opened #2090
  • Jun 22 18:49
    SethTisue commented #1432
  • Jun 22 18:48

    SethTisue on 2.13.x

    remove JDK 16 workarounds that … (compare)

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

    SethTisue on 2.13.x

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

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
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