In Scala, using case classes and subtyping versus catamorphism - which one do u recommend as best practice and why ? #idiomaticscala
2012-09-23 15:13:08@debasishg Private case class, smart constructor, no subtyping, no variance. Better abstraction, better type inference, equal performance.
2012-09-23 18:37:42@debasishg as long as you don't need specific subtypes, private case class and override the companion apply to return parent type.
2012-09-23 22:49:22@debasishg Don't use catamorphic encoding. The performance hit is pretty heavy.
2012-09-23 22:50:12@djspiewak @debasishg what do you mean by "catamorphic encoding"? i can has gist plz?
2012-09-23 23:49:30@mergeconflict @djspiewak Have a look at the Iteratee impl in scalaz done w/ a fold instead of case classes as shown in http://t.co/ZoJsDaHO
2012-09-24 00:00:31@djspiewak @debasishg Hopefully not in the long run, but right now, yes.
2012-09-24 00:05:13@mergeconflict @djspiewak @debasishg fold vs. pattern matching.
2012-09-24 00:05:26@debasishg I don't follow. That article looks like it's representing choice as case classes, and the fold is "just a fold." /cc @djspiewak
2012-09-24 00:10:17@mergeconflict @djspiewak The article uses case classes & subtyping for Done, Cont etc. but the impl uses fold .. https://t.co/HmC2fsnx
2012-09-24 00:13:25@mergeconflict @djspiewak IOW the impl doesn't use subtyping on case classes for the ADT encoding
2012-09-24 00:15:44@jsuereth I understand that. I'm asking e.g. what would Either look like without case classes? /cc @djspiewak @debasishg
2012-09-24 00:17:23@mergeconflict @jsuereth @debasishg http://t.co/jNXlvODT
2012-09-24 00:19:39@djspiewak @mergeconflict @jsuereth @debasishg So using a virtual fold method instead of pattern matching, then?
2012-09-24 00:21:12@crstry @mergeconflict @jsuereth @debasishg Yes. That is the catamorphic encoding of an ADT.
2012-09-24 00:21:32@djspiewak @mergeconflict @jsuereth @debasishg Aha. Thanks!
2012-09-24 00:22:02@djspiewak Ohhh, anonymous classes. I was imagining something terrible: a single concrete class with nullable left and right fields :P
2012-09-24 00:22:57@mergeconflict You can use concrete classes as well. I was using anonymous classes for the sake of brevity.
2012-09-24 00:23:19@djspiewak @crstry @mergeconflict @jsuereth It's inefficiency is due to the overhead of closures on the JVM ? Subtyping will be faster ?
2012-09-24 00:23:51@debasishg @crstry @mergeconflict @jsuereth That is part of the inefficiency, yes. Remember, you create a closer for even unused cases.
2012-09-24 00:24:30@debasishg @crstry @mergeconflict @jsuereth .@nuttycom came up with a clever hack to avoid *some* of this overhead, but not all.
2012-09-24 00:24:50@debasishg @crstry @mergeconflict @jsuereth It's not so much that subtyping is faster. Rather, pattern matching has less overhead.
2012-09-24 00:25:20@debasishg @djspiewak @crstry @mergeconflict to be fair, it's an interaction of Scala's encoding of closures and JIT.
2012-09-24 00:25:21@jsuereth @debasishg @crstry @mergeconflict More than that. The heap pressure from catamorphic encodings in hot paths is obscene.
2012-09-24 00:25:49@djspiewak @crstry @mergeconflict @jsuereth @nuttycom share the trick ? smart constructor as @dibblego mentioned a la none, some in scalaz ?
2012-09-24 00:25:58