Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 17:55
    SethTisue assigned #1499
  • 17:49
    SethTisue opened #1499
  • 17:47
    SethTisue edited #795
  • 17:47
    SethTisue edited #795
  • 17:47
    SethTisue edited #795
  • 17:46
    SethTisue demilestoned #754
  • 17:46
    SethTisue demilestoned #577
  • 17:46
    SethTisue commented #9697
  • 17:45
    SethTisue edited #795
  • 17:44
    SethTisue edited #795
  • 17:44
    SethTisue assigned #795
  • 17:44
    SethTisue opened #795
  • 17:08
    tlazaro commented #12038
  • 15:55
    SethTisue commented #470
  • 15:55
    SethTisue milestoned #470
  • 15:55
    SethTisue demilestoned #470
  • 15:54
    SethTisue assigned #470
  • 15:21
    SethTisue commented #2205
  • 15:21
    SethTisue commented #2205
  • 12:50
    bishabosha commented #12469
Rob Norris
@tpolecat
:-)
Eric Peters
@er1c
I have a signature like: def makeAndSetIterableField[V, T <: Iterable[V], F <: ScalarFormField[T]](attrRef: AttributeRef[T], field: F): AttributesFormField[T] that I want to use via: makeAndSetIterableField(attrRef.cast(t) /* Set[Int] */, text[Int](key, name, includeUseValueCheckbox = true)) without being explicit with type parameters makeAndSetIterableField[Int, Set[Int], ...](attrRef.cast(t) /* Set[Int] */, text[Int](key, name, includeUseValueCheckbox = true)) ... I could change the signature to something like: def makeAndSetIterableField[V, T <: Iterable[V], F <: ScalarFormField[T]](attrRef: AttributeRef[_ <: Iterable[V]], field: F): AttributesFormField[T] but then I lose the type T in the attrRef. What am I missing? (and ignore the cast red flag :)
Is this where something like (implicit tag: TypeTag[V]) would help? I guess I could try lol
Hanns Holger Rutz
@Sciss
@er1c is V actually used in the method? If not you can remove it and just write T <: Iterable[Any] since Iterable is covariant in its type-parameter.
likewise with the other parameters; if you can make them covariant, you might be able to get rid of T <: Iterable. And again F. Is it important that it is more specific than ScalarFormField? If not, scrap it, and just write field: ScalarFormField[T]
Eric Peters
@er1c
thanks, that gives me some ideas to play with
Ryan Peters
@sloshy

And another that helps people with cats imports.

@tpolecat I'm imagining a The IT Crowd style "Hello, IT... Have you tried import cats.implicits._?" for every new user who joins the chat

Gavin Bisesi
@Daenyth
Don't forget partial-unification :)
Ryan Peters
@sloshy
Actual bot prototype footage https://www.youtube.com/watch?v=PtXtIivRRKQ
Daniel Gordon
@DanielGGordon
is the only reason not to use case classes is because of the performance/memory overhead?
Ryan Peters
@sloshy
@DanielGGordon Sometimes you don't want to provide all of the things case classes do. For example say you have a class that acts as a kind of "refined" type, like a user who most definitely exists. If you base it off of case class you technically still have the copy method available so you could change it to be a user who does not actually exist. So then it's a matter of discipline on whether or not your data is correct anyway.
Rob Norris
@tpolecat
@sloshy we tried that in the header for -Ypartial-unification and it didn't really work.
Ryan Peters
@sloshy
:(
Daniel Gordon
@DanielGGordon
@sloshy oh also maybe you might not want to provide setters. case classes come with setters don't they?
Is there like a list of which methods are generated from case class? Like I know generally speaking getters, setters, apply, unapply, hashcode and toEquals.
Gavin Bisesi
@Daenyth
Setters?
Daniel Gordon
@DanielGGordon
yeah maybe that doesn't make sense
Gavin Bisesi
@Daenyth
yeah
It doesn't so much define getters either, just that the constructor items are public instead of private by default
Ryan Peters
@sloshy
copy lets you do an immutable shallow copy of one case class instance to another so that might be what you are thinking.
Gavin Bisesi
@Daenyth
It gives you equals, hashcode, copy, Product with Serializable, apply, and unapply
Daniel Gordon
@DanielGGordon
I was thinking about the constructor I think
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.