3 ms·
And you may not discover the type erasure problems until runtime. I once found an "impossible" bug in production that came of someone accidentally swapping two
by philipkglass 10y ago
And you may not discover the type erasure problems until runtime. I once found an "impossible" bug in production that came of someone accidentally swapping two values passed to a database function. We had separate DocumentId and UserId types for the values -- how could the bad line of code even compile?! Oh, type erasure; they were both Longs "underneath". (This weakness also mandates more basic testing for Scala code than you might expect for a language whose flagship company was called Typesafe.)
Yes, the Scala docs do explain that type aliases are not really distinct types, so this sort of bug could have been expected in advance. I came to Scala with no prior Java experience so I got to discover the ways the JVM leaks through on the job. I thought that I could reuse my previous knowledge about types in program design in obvious ways and just get the obviously (to me, anyway) desired behavior. Mea culpa!
- deleted 10y ago[deleted]
- kod 10y agoThat has nothing to do with type erasure. Type aliases are not distinct from the underlying type, even at compile time. You needed value classes, not aliases. example: object Example { type IdA = Long type IdB = Long def usesA(i: IdA) = "it's an A" case class IdC(i: Long) extends AnyVal case class IdD(i: Long) extends AnyVal def usesC(i: IdC) = "it's a C" val a: IdA = 1L val b: IdB = 2L val c = IdC(3L) val d = IdD(4L) usesA(a) usesA(b) usesC(c) // these won't compile // usesC(d) // usesC(a) }
- philipkglass 10y agoHow embarrassing! Thanks for correcting my mistake. I inherited someone else's code base and I thought that the type aliases were there to enforce correctness.