3 ms·
This demonstrates a major problem with development of Java since the Collections work (which was fantastic): the libraries suffer from over-engineering and surf
by carsongross 12y ago
This demonstrates a major problem with development of Java since the Collections work (which was fantastic): the libraries suffer from over-engineering and surface far too much implementation flavor in the API.
Who cares about streams? Who cares about Optional? We just want to filter a list in a clear, terse manner. (Some people do care about streams and Optional, and I wish them well, but that's orthogonal to the question at hand.)
Consider the examples given. Here they are implemented in Gosu:
getFirstJavaArticle() : Article {
return articles.firstWhere(\ article -> article.Tags.contains("Java"))
}
getAllJavaArticles() : List<Article> {
return articles.where(\ article -> article.Tags.contains("Java"))
}
groupByAuthor() : Map<String, List<Article>> {
return articles.partition( \ article -> article.Author )
}
public getDistinctTags() : Set<String> {
return articles.*Tags.toSet()
}
(I cheated a bit on the last one by just using a Set, but that's more appropriate and communicates the uniqueness of the elements in the collection to the API consumer.)
Beyond the dot-star flatmap operator, there isn't anything very fancy going on: just closures being passed to methods, returning familiar classes that don't require additional transformation to pass on to the rest of the world.
It's too bad, because this is certainly good enough. As Jack Nicholson said: What if this... is as good as it gets?