Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 08:51
    scala-jenkins milestoned #9761
  • 08:51
    lrytz review_requested #9761
  • 08:51
    lrytz opened #9761
  • 05:39
    nwk37011 synchronize #9752
  • 05:38
    nwk37011 synchronize #9752
  • Sep 15 20:28

    SethTisue on 2.12.x

    2.12: new Scala SHA (post-2.12.… (compare)

  • Sep 15 20:28
    SethTisue closed #1485
  • Sep 15 19:03
    NthPortal synchronize #9388
  • Sep 15 17:07
    julienrf commented #9388
  • Sep 15 16:37
    SethTisue commented #9388
  • Sep 15 16:36

    SethTisue on 2.12.x

    Fix BTypes.LONG.maxValueType(BT… Refactor BTypesTest#typedOpcodes Use AssertUtil.assertThrows ins… and 1 more (compare)

  • Sep 15 16:36
    SethTisue commented #9751
  • Sep 15 16:36
    SethTisue closed #9751
  • Sep 15 16:36
    SethTisue commented #9751
  • Sep 15 16:35
    SethTisue ready_for_review #9751
  • Sep 15 16:35
    SethTisue converted_to_draft #9757
  • Sep 15 16:01
    SethTisue edited #1485
  • Sep 15 15:57
    Kordyjan commented #2182
  • Sep 15 15:48
    SethTisue synchronize #1485
  • Sep 15 15:34
    SethTisue edited #1485
Daniel Gordon
@DanielGGordon
I spent 2-3 hours on this
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