> The composability of the records is the thing that's the new idea — > the idea that you can shove new behavior en passant while cloning the > record. Daniel wants to make this a core of the type system, whereas I > view it as a nice-to-have way of passing slight data structures: > that's a stunt I often pull in JavaScript and Groovy, and having to > define a new type or abuse tuples both struck me as a bit odd. And > structural typing is in general an under-appreciated way of > approaching object(ish) programming styles.
Bingo. > Daniel and I were talking over Twitter, and he seems OK with Scala's > decision to not have completeness checking for most match statements. I'm actually not OK with it, I just can't find another alternative. :-) > This always struck me as out of tune with functional programming, and > now that I'm thinking about FP and OO hybrids, I can finally figure > out why: encapsulation works differently in FP than in OO. I think if you combine this with the fact that subtyping allows any type to represent a potentially-unbounded algebra and you have the explanation. This is why Scala needed to add the semi-magical "sealed" modifier. Subtyping is a major pain, but it's quite central to OO. Daniel -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com. To unsubscribe from this group, send email to jvm-languages+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
