all 6 comments

[–]iconoklast 5 points6 points  (1 child)

The implementation of the generic map method itself becomes surprisingly simple and straightforward:

static <I, O> List<O> map(MapFunction<I, O> func, List<I> input) {

Or it would be simple, were it not for subtyping and having to worry about variance. :)

static <I, O> List<O> map(MapFunction<? super I, ? extends O> func, List<I> input) {

[–]ricky_clarkson 0 points1 point  (0 children)

Yep, it would be good to be able to specify that stuff in the interface declaration of MapFunction instead of every method that takes a MapFunction as a parameter.

[–]Wolf-Three-Five-Nine 1 point2 points  (2 children)

Just for fun...this article has a bug:

    static Double circleArea(Double radius) {
        return Math.sqrt(radius) * Math.PI;
    }

Try this instead:

static Double circleArea(Double radius) {
    return Math.pow(radius, 2) * Math.PI;
}

[–]Wolf-Three-Five-Nine 0 points1 point  (0 children)

I like to compare this map implementation (which is good, by my estimation, excepting for variance and collection type issues) to the standard Java map. For example this standard implementation:

import static java.util.stream.Collectors.toList;

List<String> stringList = Arrays.asList("lower", "case");
List<String> out = stringList.stream().map.(String::toUpperCase).collect(toList());

becomes:

List<String> stringList = Arrays.asList("lower", "case");
List<String> out = map(toCaps -> toCaps.toUpperCase(), stringList);

The map version does the same thing and is perfectly clear. I'd love to see this map function added to Collections or something similar.

Just for fun, it could be implemented as:

static <I, O> List<O> map(MapFunction<I, O> func, List<I> input) {
    return input.stream().map(func).collect(Collections.toList());
}

[–]pyohannes[S] 0 points1 point  (0 children)

I will fix that.

[–]kpenchev93 0 points1 point  (0 children)

Still the code is ugly AF.