Hello Ben, > However, previously in our code we were using the implicit Scala map > function on the Result<R> instance ( as returned by Result.fetch() ). Using > the Scala implicit conflicts with the new API, so we've just decided to > ditch the Scala map in favor of supplying a RecordMapper that does the same > thing.
Thanks for sharing this. Interesting finding. It seems quite hard to achieve backwards-compatibility in Java, then, with those implicit defs... So this implicit Scala map function was actually generated from scala.collection.JavaConversions.asScalaIterator().map()? That's a bit unfortunate. To my understanding, these implicit defs are applied only *after* checking if there is an actual map() method on the original (unconverted) target type? I.e. result.map() should be more specific than asScalaIterator(result).map() Can you suggest some API evolution best practices to me, in order to avoid such problems in the future, wherever possible? Cheers Lukas 2012/12/12 Ben Hood <[email protected]>: > Hey, > > This is just an FYI for those who were using a pre 2.6 version of JOOQ in a > Scala app. > > One of the improvements in the 2.6 API is the inclusion of the following > call on a Result instance: > > <E> List<E> map(RecordMapper<? super R, E> mapper); > > However, previously in our code we were using the implicit Scala map > function on the Result<R> instance ( as returned by Result.fetch() ). Using > the Scala implicit conflicts with the new API, so we've just decided to > ditch the Scala map in favor of supplying a RecordMapper that does the same > thing. > > Hope this helps anybody porting their code. > > Cheers, > > Ben
