jkostaras at gmail.com
Thu Sep 5 12:47:01 PDT 2013
> we ran a Hackday <http://wikieducator.org/JCrete2013:Hackathon> on
> lambdas on 22nd of August in Crete.
> Around 25 developers participated in this hackday, watched the
> powerpoint presentation and tried the exercises.
> A number of comments came up which I describe here:
> 1. Instead of having to type:
> return Collections.unmodifiableList(products.stream().filter(p ->
> p.getPrice() > minPrice && p.getPrice() <
> we should be able to type:
> return products.stream().filter(p -> p.getPrice() > minPrice &&
> p.getPrice() < maxPrice).collect(Collectors.*toUnmodifiableList*()));
> which should use a mutable list for internal calculations, but in the end
> it would return an unmodifiableList.
> 2. All these mapToInt(), mapToDouble() etc. methods make the API uglier
> and more difficult to maintain in the future. Are the reasons for
> introducing these methods for performance reasons to avoid autoboxing?
> 3. The developers appreciated the new Comparators API. However, in the
> following example
> Comparator<Book> byTitle = Comparator.comparing((Book book) ->
> shouldn't be able to infer that book is of type Book since it is the type
> in Comparator<Book>?
> There has been of course the usual argumentation that instead of
> products.stream().filter(p -> p.getPrice() > minPrice && p.getPrice() <
> they 'd like to have
> products.filter(getPrice() > minPrice && getPrice() < maxPrice).toList();
> but there have also been positive feedback about the first syntax since
> notifies the developer about lazyness.
> Looking forward your feedback on the above.
More information about the lambda-dev