No subject

John Kostaras jkostaras at gmail.com
Thu Sep 5 12:47:01 PDT 2013


>  Hi,
>
> 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() <
> maxPrice).collect(Collectors.toList()));
> 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) ->
> book.getTitle());
> 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() <
> maxPrice).collect(Collectors.toList());
>
> 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.
>
> Regards,
>
> John
>


More information about the lambda-dev mailing list