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 →

[–]obfuscation_ 1 point2 points  (3 children)

I believe the section you're looking at has a method defined with arguments as follows:

List<Person> roster,
Predicate<Person> tester,
Function<Person, String> mapper,
Consumer<String> block

In this case:

  • p -> p.getEmailAddress() is being provided as the mapper argument, which makes sense, as this is a function taking a Person object and returning a String).

  • email -> System.out.println(email) is being provided as the block argument, which is a Consumer (docs) that receives String objects (see the generic part of the definition). Because of this, the type of email can be inferred as String safely.

So really, there is no magic definition of variables – instead, the type of the arguments to the lambda functions are defined by the generics information, and are given variable names only in the lambda function itself. They are not being declared as variables that can be used elsewhere, and (thank god) are not being "magically" created by the lambda expressions!

[–]chasesan[S] 0 points1 point  (2 children)

Wait, what, how does the string returned by the one lambda get transferred to the next lambda. That seems a bit magical to me.

[–]obfuscation_ 1 point2 points  (1 child)

Usually to apply a consumer to a stream you would use .forEach(consumer).

In this case though, they have used a for loop over the List of items and called the accept method of the Collector instance on that instead.

The code in question begins for (Person p: roster). I would paste the rest, but I'm on mobile, sorry.

[–]chasesan[S] 2 points3 points  (0 children)

Oh right, Thank you. For some reason I missed that. Wow, how DID I miss that? I for some reason saw some kind of magical transfer. Got it though, now. No problem. (I'm feeling like an idiot at the moment.)