Hi Lukas,
On Wed, Dec 12, 2012 at 11:23 AM, Lukas Eder <[email protected]> wrote: > Thanks for sharing this. Interesting finding. It seems quite hard to > achieve backwards-compatibility in Java, then, with those implicit > defs... > One could argue OTOH that the map() call in JOOQ 2.6 has shadowed a functional idiom, but OTOH, as an API maintainer, it does feel as if you are maintaining a JS library that people are monkey patching :-) > 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() > Um, I think you know more about Scala type inference than I do - I might have to ask around to find somebody who knows the answer to this. > > Can you suggest some API evolution best practices to me, in order to > avoid such problems in the future, wherever possible? > > In this instance, you could rename the call from map/1 to mapRecord/1 (but that obviously breaks code using map/1 as of release 2.6). Generally speaking, I guess the only thing one could practically do is to maintain a pseudo-keyword list of commonly used function names that you don't want to overload. Having said that though, this would mean you'd have to ban map(), filter(), foldl(), reducel(), zip(), etc. Sorry for not being all that helpful, Cheers, Ben
