Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 01:14
    som-snytt commented #9824
  • 01:08
    som-snytt commented #9824
  • 00:54
    SethTisue commented #2266
  • 00:54
    SethTisue labeled #2266
  • 00:49
    alvinj commented #2266
  • Dec 08 23:28
    SethTisue commented #800
  • Dec 08 20:47
    Nicolapps opened #2270
  • Dec 08 20:46
    tribbloid commented #9824
  • Dec 08 17:16

    eed3si9n on main

    Update overview.md Fix grammat… Merge pull request #2269 from d… (compare)

  • Dec 08 17:16
    eed3si9n closed #2269
  • Dec 08 14:05
    Sporarum edited #9792
  • Dec 08 11:13
    dzzxjl opened #2269
  • Dec 08 09:16
    joroKr21 commented #12511
  • Dec 08 09:16
    akhaldi94 commented #2262
  • Dec 08 09:13
    akhaldi94 synchronize #2262
  • Dec 08 07:34
    lrytz edited #12511
  • Dec 08 03:53
    tribbloid synchronize #9824
  • Dec 08 03:52
    tribbloid reopened #9824
  • Dec 08 03:52
    tribbloid commented #9824
  • Dec 08 03:50
    tribbloid commented #9824
Ryan Peters
@sloshy
i.e. myCaseClass.copy(name = "newName")
Case classes are best whenever you just have "some data with a shape to it", and if you need more control over how that works a class can work better. Usually (95% of the time) I go with case classes because they're so convenient.
Daniel Gordon
@DanielGGordon

Found a summary that said:

apply
unapply
accessor methods are created for each constructor parameter
copy
equals and hashCode
toString

Ryan Peters
@sloshy
I wouldn't know anything about efficiency. I don't think it's an issue until it's an issue for you. Profile and whatnot if you have to.
Daniel Gordon
@DanielGGordon
So in terms of the performance - is it really just a memory overhead? There isn't actually a runtime difference just because the class has more methods?
Ryan Peters
@sloshy
Also while we're here - make all your case classes/objects final. Inheritance with those is kind of wonky sometimes
Daniel Gordon
@DanielGGordon
final means you can't extend it right?
Ryan Peters
@sloshy
yes
They can extend other things like traits - just not each other, I wouldn't recommend it
Martijn Hoekstra
@martijnhoekstra
an instance of a case class probably isn't going to be bigger than one of a "regular" class
at least, I don't know why it should be
AFAIK the state on automatic final of case classes still is that Martin has some use case for extending case classes in the compiler. I wonder if that's still the case for scala 3
Daniel Gordon
@DanielGGordon
Well @martijnhoekstra for example if I just make a class, there are methods you get when you use the case keyword, so isn't it guaranteed you will have a larger memory footprint for the case class? What I'm not sure about, is if this actually translates to each instance of the class having a large footprint or not.
Martijn Hoekstra
@martijnhoekstra
I believe that you will get a bigger memory footprint for the class itself only, which means once per class, not once per instance of a class
I never worried about this before, so I'm not entirely sure
Daniel Gordon
@DanielGGordon
ok in that case it's negligible
Rob Norris
@tpolecat
Instance size is a constant + memory required for fields
methods don't have a per-instance cost
Soren
@srnb_gitlab
I wrote almost 400 lines of my first C++ code ever in the past two days
And oh boy has it made me really appreciate having cats/fs2
What Even Is A Mutex?:tm:
Rob Norris
@tpolecat
Ironically we don't have an answer to that. I need a re-entrant mutex that understands fibers and it's impossible to write one at the moment.
Robert D. Blanchet Jr.
@blanchet4forte
Anyone here use reactive mongo? I'm using it with play and play.json and I'm trying to insert a document but its complaining that it can't find the implicit Json Format for the object I'm trying to insert even though its declared in its companion object that is getting imported
Error:(63, 15) No Json serializer as JsObject found for type co.firstfoundry.lagom.scaladsl.api.mongo.OffsetDocument. Try to implement an implicit OWrites or OFormat for this type. .one(offsetDocument)) Error:(63, 15) not enough arguments for method one: (implicit ec: scala.concurrent.ExecutionContext, implicit writer: play.api.libs.json.OWrites[co.firstfoundry.lagom.scaladsl.api.mongo.OffsetDocument])scala.concurrent.Future[reactivemongo.api.commands.WriteResult]. Unspecified value parameter writer. .one(offsetDocument))
Robert D. Blanchet Jr.
@blanchet4forte
figured it out.. my implicit was Format but if I change it to OFormat it finds it.
Ichoran
@Ichoran
@srnb_gitlab - Why do you need to write C++ instead of Rust?
And anyway, Java has mutexes also under ever-so-friendly names like ConcurrentReadWriteLock.
Rob Norris
@tpolecat
Need the equivalent for when there are no threads.
Gavin Bisesi
@Daenyth
TIL json number is a Double and will happily round even integral Long values :trollface:
nafg
@nafg
@Daenyth in what context?
Rob Norris
@tpolecat
yes, the 52-bit integers we have all been asking for
Gavin Bisesi
@Daenyth
@nafg in the context of json parsing
Rob Norris
@tpolecat
> 9223372036854775807
9223372036854776000
close enough eh
Gavin Bisesi
@Daenyth
@tpolecat is that the cutoff? Thanks, we want to see how many of our apis ship ids that get broken this way
Rob Norris
@tpolecat
Yeah it's IEEE 754 floating point so you get 52 bits of mantissa and 12 bits of exponent. At least in Javascript. I don't know if JSON itself specifies it.
Martijn Hoekstra
@martijnhoekstra
Json specifies arbitrary precision
Rob Norris
@tpolecat
Ok.
nafg
@nafg
@Daenyth parsing it with what?
Gavin Bisesi
@Daenyth
JSON.parse
Martijn Hoekstra
@martijnhoekstra
But stresses that if you want to be interoperable, you probably need to do IEEE or you'll probably have a bad time
Gavin Bisesi
@Daenyth
@tpolecat json doesn't "specify" much
nafg
@nafg
@Daenyth in Javascript? Javascript doesn't have Double or Long
Gavin Bisesi
@Daenyth
the json "spec" is that all json numbers are infinite-length perfect precision
@nafg yes, that's why I said number
The context is that I have a jvm backend that has Long values as ids for certain things, and javascript is awful
Martijn Hoekstra
@martijnhoekstra
With an "but if you do that, you're sort of asking for it" disclaimer
Gavin Bisesi
@Daenyth
I wish there was some consensus on a "reasonable json" spec
nafg
@nafg
@Daenyth JSON.parse is in javascript, not on the JVM