The Mapper change

Sam Pullara spullara at gmail.com
Wed Nov 7 09:31:04 PST 2012


Hi all,

It is pretty clear that none (few?) of us noticed that Mapper and related SAM interfaces were changing in a way that doesn't match our expectations and caught us off guard when we saw the change announced on the lambda-dev list. We should at least have the discussion now about whether it makes sense to deviate from convention for this case. Here was the original description of what was happening, I read this but didn't really internalize that it was changing the order:

"- The argument lists are structured so that specializations act on the first argument(s), so IntMapper<T> is a specialization of Mapper<R,T>, and IntBinaryOperator is a specialization of BinaryOperator<T>."

But when I saw it this way in the announcement, it was much more obvious this was a large change from the status quo:

"Heads up: Mapper<T, R> -> Mapper<R, T>"

I can sympathize with Brian that it would have been much better if I had noticed this then and raised my concerns. I would understand the change if there weren't so many examples in other languages/libraries like Guava, Scala, C# and even Java (Map<Key, Value>) that make the other choice. What do people think about this change? Did some of you notice it and agree with it? A tangential issue is that this change is aggravated by Java's single letter type declarations convention for generics. It would be much more palatable if they were something like Mapper<To, From>.

Sam



More information about the lambda-libs-spec-observers mailing list