by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 22:27
    neko-kai opened #123
  • 19:21
    dotty-bot commented #9053
  • 18:22
    odersky synchronize #9083
  • 17:47
    liufengyun commented #9053
  • 17:45
    Blaisorblade commented #9076
  • 17:34
    smarter commented #9086
  • 17:24
    odersky commented #9086
  • 17:22
    odersky synchronize #9086
  • 17:01
    odersky edited #9083
  • 16:57
    smarter commented #9076
  • 16:56
    odersky synchronize #9083
  • 16:41
    odersky edited #9083
  • 16:40
    odersky synchronize #9083
  • 16:03
    Blaisorblade commented #9076
  • 16:02
    Blaisorblade commented #9076
  • 16:00
    jieyouxu starred lampepfl/dotty
  • 15:57
    smarter reopened #9061
  • 15:57
    smarter commented #9061
  • 15:56
    smarter assigned #9086
  • 15:55
    smarter commented #9084
Nicolas Rinaudo
@nrinaudo
scala> enum Foo {
     |   case Bar(i: Int)
     |   case Baz(b: Boolean)
     | }
     | 
     | List(new Foo.Bar(1), new Foo.Baz(true))
// defined class Foo
val res1: List[Foo & Product & Serializable] = List(Bar(1), Baz(true))
I was really hoping for the Product & Serializable wart to disappear :/
Guillaume Martres
@smarter
if you don't use new then you get the apply companion that returns Foo so you just have a List[Foo]
Nicolas Rinaudo
@nrinaudo
absolutely. The wart is better hidden, but it's still here
Guillaume Martres
@smarter
but if no one uses new, then is it really worth the effort to special-case Serializable and Product in enums ?
it'd be more interesting to do this for regular sealed traits
but then it still seems a weird special-casing than you cannot opt out of
Nicolas Rinaudo
@nrinaudo
if it's complicated, probably not. But if not, and you already have a special case for case classes, why not special case ADTs?
Guillaume Martres
@smarter
what do you mean by special case for case classes ?
Nicolas Rinaudo
@nrinaudo
case classes are Product with Serializable, right?
Guillaume Martres
@smarter
it's not complicated to implement, it's just irregular
yes
but that's unconditional
Nicolas Rinaudo
@nrinaudo
I'm arguing Serializable should then be unconditional for enums
Product is slightly weirder, since not all cases need be products
Guillaume Martres
@smarter
what if I extend something which is impossible to serialize ?
Martijn Hoekstra
@martijnhoekstra
if all members of some sealed trait Foo extend Bar, then Foo extends Bar naively sounds like a reasonable rule that would solve all potential issues
Nicolas Rinaudo
@nrinaudo
don't you have the same problem with case classes?
Guillaume Martres
@smarter
@martijnhoekstra It's not completely crazy but it has the potential to break stuff
yes, you're not supposed to do that with case classes
Nicolas Rinaudo
@nrinaudo
so that's where my point of case classes are a special case came from
I was suggesting to make them less of a special case, or at least to make ADTs a special case, not just case classes
I do understand your point about breaking stuff though. I'm just not sure you'd break more stuff than currently
(I also understand that this kind of decision cannot be taken on a hunch)
Guillaume Martres
@smarter
no, you'll have to go to https://contributors.scala-lang.org/ and convince people to care :)
Nicolas Rinaudo
@nrinaudo
Ah. I thought this was the right avenue for that
ok then, thanks!
@smarter I think I'll end up crediting you for half of my slides at scaladays
Guillaume Martres
@smarter
haha
what's the topic of your talk ?
Nicolas Rinaudo
@nrinaudo
Best Practices I wish someone'd told me about
stuff like... extends Product with Serializable for ADTs
Guillaume Martres
@smarter
nice
Nicolas Rinaudo
@nrinaudo
or return Some when you can in extractors
there's a bit of a pattern :)
I'm trying to see how much of my deck is made irrelevant by dotty
Guillaume Martres
@smarter
One idea to get rid of Serializable showing up in type inference was to just add it as a parent of case clases after typechecking
since it's basically an implementation detail that no one cares about
Nicolas Rinaudo
@nrinaudo
people that work with Spark apparently care about it quite a bit
but yes, that'd work as well
Guillaume Martres
@smarter
they care about things extending Serializable
Nicolas Rinaudo
@nrinaudo
doesn't help with Product though
Guillaume Martres
@smarter
yeah I don't know what to do with Product
Nicolas Rinaudo
@nrinaudo
it's not a big deal, it's just very confusing for newcomers
Guillaume Martres
@smarter
might become irrelevant with the generic derivation stuff in dotty, or might not
agreed
hence why I think it's worth discussing on http://contributors.scala-lang.org/
Nicolas Rinaudo
@nrinaudo
and since I do a lot of work with beginners, it's something I have to explain again and agani, which is why I care
oh I absolutely intend to
(the generic derivation stuff in dotty is amazing to use, but looks absolutely nightmarish to write)