forax at univ-mlv.fr
Fri Sep 14 00:13:54 PDT 2012
On 09/14/2012 07:23 AM, Sam Pullara wrote:
> Here are some issues that I find with the current Streams implementation:
> 1) Collection is not a Stream. This means that whenever you use
> collections and want to use some of the great new features you have to
> first convert it to a stream:
> list.stream().map(l -> parseInt(l)).into(new ArrayList<>())
> I find this unnecessary. Collection could implement Stream and the
> default methods could do the conversion for me, probably by calling
> .stream() as above.
I fuly agree, it will be convenient to have such delegation mechanism.
> 2) Optional should implement more of the Stream API like flatMap and
> some others.
> Option<U> flatMap(Mapper<T, ? extends Optional<U>>)
> I also hate that with Optional.none() often needs to be witnessed and
> not a big fan of using a constructor for Optional:
> return matcher.matches() ? new Optional<>(matcher) : Optional.<Matcher>empty();
> should really be something more like (using static imports):
> return matcher.matches() ? option(matcher) : none();
Is there a document somewhere that explain the pro and cons of using
Currently I see it as a way to add a level of indirection with no real
the VM currently optimizes code that check a variable is null if the
variable is never null,
so this kind of nullcheck are free. With Optional you add a level of
indirection in any case
(null or not null) and you have an allocation if you're not lucky and
the escape analysis doesn't work.
> 3) I really, really believe that we should have something around
> Future like I have prototyped here:
> Blocking to get the result of a Future is a bad code smell in my mind
> after using Promises for a long time at Twitter. This will be a great
> opportunity to get all the APIs in line with a much better way of
> handling asynchronous work that isn't CPU bound.
I fully agree, and think you should move this question to
concurrency-interest mailing list
at least to have Doug comments on this idea.
More information about the lambda-spec-experts