Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 02:08
    NthPortal edited #12464
  • 02:08
    NthPortal labeled #12464
  • 02:08
    NthPortal opened #12464
  • Sep 23 23:32
    NthPortal commented #9388
  • Sep 23 15:25
    jxnu-liguobin edited #9754
  • Sep 23 15:16
    jxnu-liguobin synchronize #9754
  • Sep 23 15:15
    jxnu-liguobin synchronize #9754
  • Sep 23 15:13
    jxnu-liguobin synchronize #9754
  • Sep 23 15:12
    jxnu-liguobin synchronize #9754
  • Sep 23 14:54
    SethTisue labeled #9767
  • Sep 23 14:54
    JurgisSi edited #2188
  • Sep 23 14:53
    JurgisSi opened #2189
  • Sep 23 14:51
    JurgisSi opened #2188
  • Sep 23 14:48
    scala-jenkins milestoned #9767
  • Sep 23 14:48
    mrdziuban opened #9767
  • Sep 23 13:43
    SethTisue commented #9764
  • Sep 23 07:40
    lrytz commented #9764
  • Sep 23 03:05
    jxnu-liguobin review_requested #9754
  • Sep 23 02:54
    jxnu-liguobin commented #9765
  • Sep 23 02:24
    jxnu-liguobin commented #9765
Daniel Gordon
@DanielGGordon
That was the issue
Martijn Hoekstra
@martijnhoekstra
:+1:
Daniel Gordon
@DanielGGordon
Really appreciate it
Deepak Singh
@dpk3d
@martijnhoekstra totally agreed dude
Rob Norris
@tpolecat
We need an AI that helps people with regexes.
And another that helps people with cats imports.
(That one could be very simple.)
Martijn Hoekstra
@martijnhoekstra
in fact, I bet I could write a regex for the second one
Rob Norris
@tpolecat
Synergy.
Martijn Hoekstra
@martijnhoekstra
it's kinda lame that you "just" get a match exception, but I don't think you can actually do better
Fabio Labella
@SystemFw
just replaced some regexes with atto, quite pleasant
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