> 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 :-)
Well, there's a slight difference between shadowing and creating ambiguities/backwards-incompatibilities. If it's just "shadowing", I guess people have to live with it. E.g. org.jooq.Field may "shadow" java.lang.reflect.Field. Even org.jooq.Integer would be a (more extreme) case of shadowing. Besides, jOOQ's suggested practice of static-importing all methods from org.jooq.impl.Factory is probably causing conflicts in some environments, e.g. when you already static-imported stuff from java.lang.Math (both classes have static sum() and other common methods) >> 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. Well, that was my assumption / my hope. I haven't completely understood the complete impact that implicit defs have within the Scala universe. Then again, transforming org.jooq.Result into a Scala Iterator might be considered "shadowing" jOOQ's new map() method :-) >> 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). Yes, I'm sure that there are many other conflicts, too. I like short method names, though. In a Java world, they don't cause any trouble, either. > 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. That's hard to achieve. First, I'd have to maintain such a list for Scala. Then, eventually, for Groovy and maybe Fantom and Xtend... And maybe, I should also be looking at Java 8's Collection API drafts, too :-) > Sorry for not being all that helpful, Well, thanks again for starting this discussion. I hadn't thought of such a possibility before. When I have some time, I'll raise the issue on Stack Overflow. It really seems like a substantial problem in the Scala universe. I'm sure someone has thought of best practices already Cheers Lukas
