(6) collections algorithms

Collections – Part VI
Nico Ludwig (@ersatzteilchen)

2
● Collections – Part VI
TOC
– Producing Collection Objects
– Immutable Collections and defense Copies
– Empty Collections
– Tuples as pseudo Collections
– Filling Collections with structured Data
– Collections abstracting Data Processing: Stack and Queue
– Kung Fu beyond Collections: .Net's LINQ and Java's Streams

Producing Collection Objects
● Java: We already discussed Collections' simple factories producing collections in Java, but there exist more of these:
3
– The class Arrays provides similar simple factories: the method asList() produces an unmodifiable List from the passed array:
public static void main(String[] args) throws Exception {
List<String> arguments = Arrays.asList(args); // Creates an unmodifiable List from an array.
}
– Because asList() accepts a variable count of arguments, we can directly pass some values, instead of a first class array:
List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6); // Creates a List from a couple of arguments.
● .Net: There exist many means to produce collections through extension methods from the System.Linq namespace.
– E.g. producing a List from an array with the extension method ToList():
public static void Main(string[] args) {
IList<string> arguments = args.ToList(); // Creates a List from an array.
}
– .Net's class Enumerable provides the methods Range() and Repeat() (i.e. simple factories) to produce respective sequences.
● The method-call chain with ToList() produces/materializes the lists from the sequences. - The resulting list is modifiable.
IList<int> numbers = Enumerable.Range(1, 6).ToList(); // Creates a List of integers from 1 to 6 inclusively.
IList<int> sixCopiesOf42 = Enumerable.Repeat(42, 6).ToList(); // Creates a List containing six copies of the integer 42.

4
Immutable Collections – Part I
● Immutability of objects is a relevant topic meanwhile to write robust applications. How is it supported for collections?
● In C++, container objects can be idiomatically be set as const, then non-const member functions are no longer callable:
// Defines a const vector containing some ints:
const std::vector<int> numbers{1, 2, 3, 4, 5, 6};
// After the const vector was created it cannot be modified:
numbers.push_back(7); // Results in a compile time error!
// But reading is no problem:
int value = numbers[0];
– The objects managed by a const std::vector cannot be modified as well! This is called const-correctness in C++.
– (This idiomatic usage of const objects in C++ requires no further explanation.)
● In the COCOA framework there exist mutable and immutable collections separately:
// Defines an immutable NSArray containing some ints:
NSArray* numbers = @[@1, @2, @3, @4, @5, @6];
// NSArray does not expose any methods that could modify numbers, therefor we
// have to create an NSMutableArray from numbers:
NSMutableArray* mutableNumbers = [NSMutableArray arrayWithArray:numbers];
// NSMutableArray provides methods to modify the collection:
[mutableNumbers addObject:@7];
– NSMutableArray inherits from NSArray, this idea is used for other COCOA collections as well.

Immutable Collections – Part II
// Defines a list containing some ints:
IList<int> numbers = new List<int>{1, 2, 3, 4, 5, 6 };
// The mutable IList<int> will be wrapped by an immutable ReadOnlyCollection<int> (from the namespace System.Collections.ObjectModel):
ReadOnlyCollection<int> readOnlyNumbers = new ReadOnlyCollection<int>(numbers);
// ReadOnlyCollection<T> implements IList<T> so that it can partake in APIs requiring objects exposing that interface.
// But IList<T> is implemented explicitly, so potentially mutable methods can not be directly called:
readOnlyNumbers.Add(7); // Results in a compile time error.
// If ReadOnlyCollection<T> is accessed via the IList<T> interface, calling potentially mutable methods will throw a NotSupportedException.
IList<int> readOnlyNumbersAsList = readOnlyNumbers;
readOnlyNumbersAsList.Add(7); // Results in a run time error: NotSupportedException will be thrown.
5
● The .Net framework follows another principle to provide immutability: wrapping.
– Wrapping means, that a present instance is wrapped into another object in order to adopt another interface or to get another behavior.
– Alternatively List<T>'s method AsReadOnly() can be used, which directly returns readonly wrappers.
– The idea of wrapping is used for ReadOnlyDictionary as well.
– Objects implementing ICollection<T> can be checked if these are readonly with the
property ICollection<T>.IsReadOnly.
● The design pattern we've encountered here is called wrapper or adapter.
<<interface>>
IList
ReadOnlyCollection
wraps
implements
T
T
// Directly create a ReadOnlyCollection<int> from a List<int>
ReadOnlyCollection<int> readOnlyNumbers2 = new List<int>{1, 2, 3, 4, 5, 6 }.AsReadOnly();

6
Immutable Collections – Part III
● Java does also apply the wrapper principle to provide immutability.
– Java hides the wrapper type completely from the caller, but exposes an unmodifiable object implementing a collection interface.
– The unmodifiable implementation is somehow internally instantiated by the simple factory Collections.unmodifiable...().
// Defines a list containing some ints:
List<Integer> numbers = new ArrayList<>(Arrays.<Integer>asList(1, 2, 3, 4, 5, 6));
// The mutable List<int> will be wrapped by an unmodifiable List<int>:
List<Integer> readOnlyNumbers = Collections.unmodifiableList(numbers); // Calling the simple factory.
// readOnlyNumbers' potentially mutable methods can be called, but these calls will throw UnsupportedOperationExceptions.
readOnlyNumbers.add(7); // Results in a run time error: UnsupportedOperationException will be thrown.
● Java: More simple factories can be found in the class Collections as static methods (unmodifiableSet(), unmodifiableMap()).
– The return type of all of these simple factories are just interface types, the unmodifiable implementations are always hidden.
– So the UML diagram of the relations between the contributing types looks like so:
<<interface>>
List
exposes implements
HiddenUnmodifiableListImplementation
Collections
+ unmodifiableList(list : List<T>) : List<T>
instantiates
T

7
Immutable Collections – Defense Copy Pattern – Part I
● The strategy on which the discussed immutable collections are built is "forbidding mutating side effects".
● But there exists a completely different approach: collections that can not be modified, but produce new collections!
– Sorry?
● Well, when a method is called that has a "mutating-name" (e.g. Add()), a copy of the mutated collection will be returned!
– I.e. the original collection won't be changed!
– We know this strategy from string types in Java and .Net and also from c-strings (const char*):
● String-operations won't modify the original, but new strings with content different from the original string are returned.
– This strategy is sometimes called the defense copy pattern.

; Lisp: Creates a list containing some ints:
(let ((numbers '(1 2 3 4 5 6 7 8 9 )))
; Creates a new list from numbers having 42 appended:
; >numbers2: {1, 2, 3, 4, 5, 6, 7, 8, 9, 42}
; >numbers: {1, 2, 3, 4, 5, 6, 7, 8, 9}
; Creates a new list from numbers having the value 3 removed:
8
Immutable Collections – Defense Copy Pattern – Part II
● For .Net 4.5 and newer such types are available as extra NuGet package Microsoft.Collections.Immutable.
– There (namespace System.Collections.Immutable) are ImmutableList, ImmutableDictionary, some interfaces to exploit the DIP etc..
● The instances of those collections are created with simple factories, i.e. those collections don't provide public ctors.
// .Net/C#: Creates an immutable list containing some ints with the
// simple factory ImmutableList.Create:
IImmutableList<int> numbers = ImmutableList.Create(new[] { 1, 2, 3, 4, 5, 6, 7, 8, 9 });
// Creates a new immutable list from numbers having the number 42 appended:
IImmutableList<int> numbers2 = numbers.Add(42);
// >numbers2: {1, 2, 3, 4, 5, 6, 7, 8, 9, 42}, numbers: {1, 2, 3, 4, 5, 6, 7, 8, 9}
// Creates a another immutable list from numbers having the value 3 removed:
IImmutableList<int> numbers3 = numbers.Remove(3, EqualityComparer<int>.Default);
// >numbers3: {1, 2, 4, 5, 6, 7, 8, 9}, numbers: {1, 2, 3, 4, 5, 6, 7, 8, 9}
(let ((numbers2 (append numbers '(42))))
(let ((numbers3 (remove 3 numbers)))
; >numbers3: {1, 2, 4, 5, 6, 7, 8, 9}
; >numbers: {1, 2, 3, 4, 5, 6, 7, 8, 9}
)))
– If we look closely, we'll notice, that numbers won't be modified! - E.g. numbers3 doesn't have the 42 at the end!
● Well, the content of numbers is kept as defense copy, its content cannot be modified. Period!
● This strategy is somehow taken directly from functional programming languages, where side effects are frowned upon.
– Why is that useful? When we can't have side effects on collections, we can write thread safe code in a straight forward way!
– The downside of this approach is that more memory for the defense copies is required.
– It's another equation of applied computing: We get performance (thread-parallelization), but pay it with extra memory consumption!

Empty Collections – Part I
● Often collections are used as return value of an algorithm. The usual result of failure is returning a "invalid" value like null:
IList<int> result = GetNumbersFromUser();
// The returned input must be checked for nullity before accessing it!
if (null != result) {
9
public static IList<int> GetNumbersFromUser() {
IList<int> fromUser = new List<int>();
try {
// Get input from user here and fill the list fromUser...
} catch (Exception ex) { //... if something went wrong return null.
return null;
} return fromUser;
}
foreach (int item in result) {
Console.WriteLine(item);
}
}
– Checking the result for null every time after GetNumbersFromUser() was called is cumbersome and it could be forgotten!
– Another idea is to return an empty collection as the result, then no checking for nullity is required:
public static IList<int> GetNumbersFromUser() {
try {
} catch(Exception ex) { //... if something went wrong return an empty list.
return new List<int>(0);
} return fromUser;
● What we've just encountered is called the null-object design pattern.
– The idea is to return a genuine empty object instead of an invalid object, so that callers need no special treatment of results.
}
IList<int> result = GetNumbersFromUser();
// The returned input can just be iterated. No checking for "invalidity" is required!
foreach(int item in result) {
Console.WriteLine(item);
}

10
Empty Collections – Part II
● Java supports the idea of empty collections and the null-object design pattern by Collections' simple factories:
List<Integer> fromUser = new ArrayList<>();
try {
} catch (Exception ex) { //... if something went wrong return an empty list.
return Collections.emptyList();
} return fromUser;
– Besides emptyList() there exist similar simple factories producing other empty collections (Maps, Sets, Iterators etc.).
– These simple factories produce null-objects that are unmodifiable!
– The produced null-object of a specific simple factory is always identical. - Here the object Collection.EMPTY_LIST is always returned.
● The .Net framework doesn't directly support null-objects to get empty collections. Instead Enumerable's static methods
can be used:
try {
} catch(Exception ex) { //... if something went wrong return an empty list.
return Enumerable.Empty<int>().ToList(); // uses System.Linq.Enumerable
} return fromUser;
– The method-call chain Empty().ToList() produces/materializes an empty list. - The resulting list is modifiable.
– The methods ToDictionary() and ToArray() can be used to create empty collections the same way.

11
● There are structures that are not exactly collections, but help solving collection-like problems.
– Tuples are types, which are data containers, but not yet collections.
● Tuples.
– Originally tuples are taken from maths, where they represent an ordered and finite sequence of items.
● E.g. the coordinates values of a spatial vector can be expressed as tuple:
● a is represented as 3-tuple, sometimes also called triple, a 1-tuple can be
⃗a=(2
75
) can be represented as a tuple like so: acomp=(2,7,5)
called single or monad, a 2-tuple can be called pair or twin or couple or double, others are simply n-tuples.
● The "items" of the tuple are called components: 2, 7, and 5 are the components of a.
– Extra: In programming the count and the static types of the components is not restricted. Esp. components needn't to be numbers!
● In .Net we can have up to seven components, more components are put into effect by setting tuples as rest component of a 7-tuple.
● Using .Net Tuples:
Tuples as Pseudo Collections – Part I
// There exist several generic overloads for Tuples having different counts of components:
public class Tuple<T1, T2> { /* pass */ }
public class Tuple<T1, T2, T3> { /* pass */ } // etc.
// Creating some tuples:
Tuple<int, int, int> a = new Tuple<int, int, int>(2, 7, 5); // The representation of the spatial vector a.
Tuple<int, string> twoTuple = Tuple.Create(2, "two"); // A couple using the simple factory Tuple.Create and type inference.
Tuple<string, int, double> triple = Tuple.Create("three", 3, .7); // A triple.
// Accessing a tuple's components:
Console.WriteLine("couple's item1: {0} couple's item2: {1}", twoTuple.Item1, twoTuple.Item2); // Mind the fix property names Item1 and Item2!
// >couple's item1: 2, couple's item2: two

Tuples as Pseudo Collections – Part II
● Tuples have been added to .Net because the (then) new first class .Net language F# introduced tuples as genuine concept.
12
– F# provides integrated syntactical support for tuples, similar to the support of arrays in other languages:
// Creating some tuples with F#' integrated syntax:
let a = (2, 7, 5) // The representation of the spatial vector a. The type is inferred to (int * int * int).
let twoTuple = (2, "two") // A couple. The inferred tuple type is (int * string).
// Accessing a couple's components:
printfn "couple's item1: %A couple's item2: %A" (fst twoTuple) (snd twoTuple)
// >couple's item1: 2, couple's item2: "two"
● Collections of Tuples are common sense: Why creating a UDT for car, if we can just use a Tuple as a "container"?
Tuple<int, string>[] cars = new[] { // A car represented by tuples (int Horsepower * string Name)
Tuple.Create(200, "500 Abarth Assetto Corse"),
Tuple.Create(130, "Ford Focus 2.0"),
Tuple.Create(55, "VW Kaffeemühle"),
Tuple.Create(354, "Lotus Esprit V8"),
Tuple.Create(112, "Alfa Romeo Giulia ti Super")
};
– It should be underscored that the semantics of "car" is no longer present. Its abstraction was flattened into a (int * string) tuple.
● A (int * string) tuple could also represent (int Phonenumber * string Name).
● Java provides no dedicated UDTs to represent tuples, but those can be created easily.

Filling Collections with Data – .Net/C#
● Many languages provide ways to fill collections with new objects in a concise and compact manner. Let's review those.
13
– We mainly discuss compact ways to instantiate objects in order to fill collections directly or even literally.
● Anonymous types: Besides filling collections with tuples, C# allows filling collections with instances of anonymous types:
Tuple<int, string>[] cars = new[] { // A car represented by tuples
// (int Horsepower * string Name)
Tuple.Create(200, "500 Abarth Assetto Corse"),
Tuple.Create(130, "Ford Focus 2.0"),
Tuple.Create(55, "VW Kaffeemühle"),
Tuple.Create(354, "Lotus Esprit V8"),
Tuple.Create(112, "Alfa Romeo Giulia ti Super")
● Anonymous types as alternative to .Net Tuples:
– Pro: anonymous types have richer semantics, because named properties can be used ad hoc.
– Contra: It's needed to use type inference (var), which makes code more arcane. Instances can't be returned from or passed to methods.
● However, we could use dynamic typing.
};
var cars = new[] { // A car represented by instances of anonymous types
// {int Horsepower, string Name}
new { Horsepower = 200, Name = "500 Abarth Assetto Corse" },
new { Horsepower = 130, Name = "Ford Focus 2.0" },
new { Horsepower = 55, Name = "VW Kaffeemühle" },
new { Horsepower = 354, Name = "Lotus Esprit V8" },
new { Horsepower = 112, Name = "Alfa Romeo Giulia ti Super" }
};

Filling Collections with Data – Groovy and JavaScript
● Groovy allows defining lists of maps (associative collections). The maps act like bags of properties as fully blown objects:
def cars = [ // A car represented by instances of maps
// [Horsepower : Integer, Name : String]
[ HorsePower : 200, Name : "500 Abarth Assetto Corse" ],
[ HorsePower : 130, Name : "Ford Focus 2.0" ],
[ HorsePower : 55, Name : "VW Kaffeemühle" ],
[ HorsePower : 354, Name : "Lotus Esprit V8" ],
[ HorsePower : 112, Name : "Alfa Romeo Giulia ti Super" ]
]
● In JavaScript, we have true dynamic typing, in which we don't need specific types. We can just write object literals directly.
14
– Here we have an array holding five object literals representing cars:
var cars = [ // A car represented by object literals
// {Horsepower, Name}
{ HorsePower : 200, Name : "500 Abarth Assetto Corse" },
{ HorsePower : 130, Name : "Ford Focus 2.0" },
{ HorsePower : 55, Name : "VW Kaffeemühle" },
{ HorsePower : 354, Name : "Lotus Esprit V8" },
{ HorsePower : 112, Name : "Alfa Romeo Giulia ti Super" }
]
● Java does not yet provide simple means to freely define instances (to be used for filling collections).
– Following the Java philosophy a suitable JVM language (like Scala or Groovy) should be used.

Filling Collections – do it in Bulk
● Collections can also be created along with a bulk of data, which can yield performance benefits due to efficient capacitation:
15
– (Not all platforms apply capacity control on bulk operations!)
// Java; instead of adding items to a list with a loop...
List<Integer> numbers = new ArrayList<>();
for (int item : new int[]{1, 2, 3, 4}) {
numbers.add(item);
● Often collections can also be filled with items in bulk after creation:
}
// … the list could be initialized with another "ad hoc" collection like an array:
List<Integer> numbers2 = new ArrayList<>(Arrays.asList(1, 2, 3, 4));
// C#; instead of adding items to a list with a collection initializer or loop...
IList<int> numbers = new List<int>{1, 2, 3, 4};
IList<int> numbers2 = new List<int>();
foreach (int item in new []{1, 2, 3, 4}) {
numbers2.Add(item);
}
// … the list could be initialized with another "ad hoc" collection like an array:
IList<int> numbers3 = new List<int>(new []{1, 2, 3, 4});
// Java; adding a couple of items to a list in bulk:
List<Integer> numbers = new ArrayList<>();
numbers.addAll(Arrays.asList(1, 2, 3, 4))
// Alternatively Collections.addAll() can be used (its usually faster):
Collections.addAll(numbers, 1, 2, 3, 4);
// C#; adding a couple of items to a list in bulk:
List<int> numbers = new List<int>();
// (Mind that AddRange() isn't available via the interface IList!)
numbers.AddRange(new []{1,2,3,4});

Collections abstracting Data Processing – Stack
● There exist collections that directly represent the ways data is processed in computing whilst holding the data.
– We'll discuss the collections stack and queue.
– (The heap is also a collection of this category, but we'll ignore it in this course.)
● The idea of a stack is to take the put-in items out in the reverse order. This principle is called Last-In-First-Out (LIFO).
● E.g. assume that we want to put waypoints on a hike and we want to reach the waypoints again when we hike back.
– After we hiked there, we get following stack of visited waypoints (we start on 0km and 25km was the last visited waypoint):
waypoints
25
15
3
4
2
– When we hike back, we pick up the waypoints in the reverse order of visitation (we start on the last waypoint visited and drill down):
waypoints 16
● Now we'll put this into code.
0 5
25
15
0 5
1
2
4
1
3

17
Collections abstracting Data Processing – Stack –
fundamental Operations
● Let's discuss the .Net collection Stack:
– The method Push() pushes items on the stack:
// Create a Stack and push four waypoint km-marks on it:
Stack<int> waypoints = new Stack<int>(4);
waypoints.Push(0);
waypoints.Push(5);
waypoints.Push(15);
waypoints.Push(25);
– The method Pop() pops items from the stack (LIFO):
int lastWaypoint = waypoints.Pop();
// >lastWaypoint evaluates to 25, because it was put in last
– The method Peek() returns the last pushed item, but doesn't pop it from the stack.
int penultimateWaypoint = waypoints.Peek();
// >penultimateWaypoint evaluates to 15, because it was put in penultimately
– If Pop() or Peek() are applied on an empty Stack an InvalidOperationException will be thrown.
25
15
waypoints 0 5
● Stack collection types on other platforms: C++ STL provides std::stack (<stack>) and Java provides Stack.

Collections abstracting Data Processing – Queue
● The idea of a queue is to take the put-in items out in the same order. This principle is called First-In-First-Out (FIFO).
18
● E.g. assume that we want to read emails in the order they receive the mailbox.
– The emails are received in this order:
"What an offer!..."
"Honey, could you..."
"Customer wants..."
3
1
4
– When we're going to read the emails we read them in the same order, in which they have been received:
● Now we'll put this into code.
"Dinner at 7pm..." mailbox
2
"What an offer!..."
"Customer wants..."
3
1
"Dinner at 7pm..." mailbox
4
2

19
Collections abstracting Data Processing – Queue –
fundamental Operations
● Let's discuss the .Net collection Queue:
– The method Enqueue() enqueues items into the queue:
// Create a Queue and enqueue four emails in receipt order:
Queue<string> mailbox = new Queue<string>(4);
mailbox.Enqueue("Dinner at 7pm...");
mailbox.Enqueue("Customer wants...");
mailbox.Enqueue("Honey, could you...");
mailbox.Enqueue("What an offer!...");
– The method Dequeue() dequeues items from the queue (FIFO):
string firstEmail = mailbox.Dequeue();
// >firstEmail evaluates to "Dinner at 7pm...", because it was put in at first
– The method Peek() returns the last enqueued item, but doesn't dequeue it from the queue.
"What an offer!..."
"Customer wants..."
string secondEmail = mailbox.Peek();
// >secondEmail evaluates to "Customer wants...", because it was put in at second
"Dinner at 7pm..."
– If Dequeue() or Peek() are applied on an empty Queue an InvalidOperationException will be thrown.
mailbox
● Queue collection types on other platforms: C++ STL provides std::queue/std::priority_queue (both in <queue>) and
std::deque (<deque>). Among others, Java provides LinkedList as implementation of the interface Queue.

20
Kung Fu beyond Collections – Part I
● Up to now we've mentioned functional programming (fp) languages a lot in the context of collections.
– The interesting point is that those languages deal with data in a special way: data is generally immutable after creation.
– The lack of mutability, which is fundamental for, e.g. imperative languages, leads to fps having mighty features for data creation:
● Support of immutability, list comprehensions, generic types, type inference.
– The "main stream" languages are going to adopt or have already adopted these features as new language idioms.
● Why are these adopting fp idioms?
– The most important point is more productivity whilst programming.
– A secondary aspect is that immutable types makes writing threadsafe a piece of cake.
● Modern code should exploit the availability of parallel computing power today.
● You should know or learn about these features! They are real game changers for programmers!
● Let's rewrite an imperative code snippet that produces a new collection from a present collection.

Kung Fu beyond Collections – Part II
● We have a list of numbers and we want to filter the odd numbers out to get only the even numbers, the classical way:
// C#
IList<int> numbers = new List<int>{ 1, 2, 3, 4, 5, 6, 7, 8, 9 };
IList<int> evenNumbers = new List<int>();
foreach(int number in numbers) {
if (0 == number % 2) {
evenNumbers.Add(number);
}
}
– In both snippets we have a couple of statements, esp. a loop, a branch and adding elements to an initially empty collection, which
will be filled. We already discussed this idea, when list comprehensions were presented: here we have sophisticated list compr.
21
● Now we'll rewrite the snippets using fp features of C# and Java (and Groovy and Scala):
IList<int> evenNumbers = ( from number in numbers
where 0 == number % 2
select number).ToList();
// >{2, 4, 6, 8}
// Java
List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9);
List<Integer> evenNumbers = new ArrayList<>();
for(int number : numbers) {
if (0 == number % 2) {
evenNumbers.add(number);
}
}
List<Integer> evenNumbers =
Stream.of(1, 2, 3, 4, 5, 6, 7, 8, 9)
.filter(number -> 0 == number%2)
.collect(Collectors.toList());
// >{2, 4, 6, 8}
// Groovy
def numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9]
def evenNumbers = numbers.grep{0 == it % 2}
// >[2, 4, 6, 8]
// Scala
def numbers = List(1, 2, 3, 4, 5, 6, 7, 8, 9)
def evenNumbers = numbers.filter(number => 0 == number % 2)
// >List(2, 4, 6, 8)

22
Kung Fu beyond Collections – Part III
● What we saw in action were .Net's LINQ and Java's streams API.
// .Net's LINQ
IList<int> evenNumbers = (from number in numbers
where 0 == number % 2
select number).ToList();
// >{2, 4, 6, 8}
– In both cases we don't have a couple of statements, but rather single expressions describing the results of the operations.
– => LINQ and streams support a declarative programming style instead of an imperative programming style.
● We'll not discuss LINQ and streams in this lecture, because there are some advanced idioms to understand:
– Generic types
– Type inference
– Lambda expressions
– Fluid interfaces and the "pipes and filters" architectural style
// Java's streams
List<Integer> evenNumbers =
Stream.of(1, 2, 3, 4, 5, 6, 7, 8, 9)
.filter(number -> 0 == number%2)
.collect(Collectors.toList());
// >{2, 4, 6, 8}

(6) collections algorithms

More Related Content

What's hot (19)

Similar to (6) collections algorithms (20)

More from Nico Ludwig (20)

Recently uploaded (20)

(6) collections algorithms

Editor's Notes