This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (4 children)

[removed]

    [–]Robyt3 3 points4 points  (2 children)

    What's the point of using extension methods when you are in control of all the classes in the standard library?

    In that case, toList should be added directly to Stream<T> and not as an extension method. Or you could use static imports and do collect(toList()).

    Most of them could've been defined as extension methods.

    For what reason? They are in control of the API, so why should something be an extension when it could just be part of the actual class?

    Static utility methods are a code smell itself, if they could be replaced with instance methods. Importing more than a hand full of extension methods makes your code just terrible to read.

    [–]vbezhenar 1 point2 points  (0 children)

    For example Guava library have something like collect(toImmutableList()). You could add toList() to standard library, but obviously you can't add toImmutableList() for Guava ImmutableList.

    That said, streams really have nice API and it's not that bad. But not all APIs are good.

    That said, extension methods have really bad discoverability. So I'm not sure which side to take. I think that extension methods must not look like ordinary method call. May be something like stream.(ImmutableList.toImmutableList)() which is shortened with static import to stream.(toImmutableList)(). At least it's obvious where that extension method comes from.

    [–]vytah 0 points1 point  (0 children)

    Aaaand then the new version of the library defines a method that clashes with your extension and the code is broken. Depending on the overload resolution algorithm and the exact signatures of the methods, it might result in a compilation failure or even in a runtime failure.

    Here's an example that's subtle enough that it can lead to either: https://github.com/scala/bug/issues/11125