3 ms·

I don't see how a case-class is different than a non-case-class from a Type perspective? It was my impression it was just sugar around generating copy, equals,

• pron 13y ago
  > I don't see how the sugar makes them a fundamentally different kind of Type system? They're not sugar. Their crucial feature is that they can't form an inheritance hierarchy, which doesn't work well in an algebraic type system. > And Structural Typing is just Reflection I thought... Which again doesn't feel like an alternative Type system. The point is that you can write (and obviously people have) a big, complex piece of software just with inheritance-based types, or just with algebraic types, or just with duck types. They all serve quite nicely. It is completely unnecessary to put them all in a single language (other than to advance compiler technology), and worse than that: putting them all together takes away their respective advantages and causes a lot of confusion.
  • ssmoot 13y ago
    I don't think you can write idiomatic Scala with any one of those things exclusively. And I don't see why you'd even try. You might as we'll be arguing that the language shouldn't have for-comprehensions, lambdas, pattern matching or keyword arguments the way I see it. These things (types) do have uses, but not as competing systems in Scala, but Features. I want to write c#'s using() statement, I'm not especially worried about performance, I can't go and add IDisposable to everything because I want to use it with other people's code and I don't feel like writing a Type Class every time I need to work with a new type. Structural typing is a really convenient feature for that. Case classes are just Scala's version of a data-object. If you didn't have them you'd just be writing your own version, poorly, and forgetting about hash code and equals and all the other stuff until it bit you. I really don't see a rationale here for removing these other than you find it offensive. I use Scala because of these things.