在我的气喘吁吁的困惑之后,有什么好的资源可以解释新的Scala 2.8集合库是如何构建的.我有兴趣找到有关以下内容如何组合在一起的一些信息:
集合类/性状本身(例如List
,Iterable
)
为什么存在Like类(例如TraversableLike
)
伴侣方法的用途(例如List.companion
)
我如何知道implicit
给定点的范围内的对象
Daniel C. So.. 188
Foreword
There's a 2.8 collection walk-through by Martin Odersky which should probably be your first reference. It has been supplemented as well with architectural notes, which will be of particular interest to those who want to design their own collections.
The rest of this answer was written way before any such thing existed (in fact, before 2.8.0 itself was released).
You can find a paper about it as Scala SID #3. Other papers in that area should be interesting as well to people interested in the differences between Scala 2.7 and 2.8.
我将从论文中引用,有选择地,并与我的一些想法相辅相成.还有一些图像由Matthias在decodified.com上生成,原始的SVG文件可以在这里找到.
集合类/特征本身实际上,集合有三个特征层次结构:一个用于可变集合,一个用于不可变集合,另一个不对集合做任何假设.
在Scala 2.9中引入了并行,串行和并行并行集合之间的区别.我将在下一节中讨论它们.本节中描述的层次结构仅指非并行集合.
下图显示了Scala 2.8引入的非特定层次结构:
显示的所有元素都是特征.在另外两个层次结构中,还有直接继承特征的类以及可以通过隐式转换为包装类来查看属于该层次结构的类.这些图表的图例可以在它们之后找到.
不可变层次结构的图表:
可变层次结构图:
传说:
这是集合层次结构的缩写ASCII描述,适用于那些看不到图像的人.
Traversable | | Iterable | +------------------+--------------------+ Map Set Seq | | | | +----+----+ +-----+------+ Sorted Map SortedSet BitSet Buffer Vector LinearSeq并行集合
当Scala 2.9引入并行集合时,其中一个设计目标是尽可能无缝地使用它们.用最简单的术语来说,可以用并行的方式替换非并行(串行)集合,并立即获得好处.
但是,由于此之前的所有集合都是串行的,因此许多使用它们的算法都假设并依赖于它们是串行的事实.用这种假设喂入方法的并行集合将失败.因此,上一节中描述的所有层次结构都要求进行串行处理.
创建了两个新的层次结构来支持并行集合.
并行集合层次具有的性状相同的名称,但前面有Par
:ParIterable
,ParSeq
,ParMap
和ParSet
.请注意,没有ParTraversable
,因为任何支持并行访问的集合都能够支持更强的ParIterable
特性.它也没有一些更专业的特征存在于串行层次结构中.整个层次结构位于目录下scala.collection.parallel
.
实现并行的集合类也各不相同,有ParHashMap
和ParHashSet
两个可变和不可变的并行收集,加上ParRange
与ParVector
实施immutable.ParSeq
和ParArray
执行mutable.ParSeq
.
另一个层次也存在,反映串行和并行集合的特点,但有一个前缀Gen
:GenTraversable
,GenIterable
,GenSeq
,GenMap
和GenSet
.这些特征是并行和连续集合的父级.这意味着采用a的方法Seq
无法接收并行集合,但是采用a的方法GenSeq
可以使用串行和并行集合.
鉴于这些层次结构的结构,为Scala 2.8编写的代码与Scala 2.9完全兼容,并要求串行行为.没有被重写,它无法利用并行集合,但所需的更改非常小.
任何集合都可以通过调用par
它上面的方法转换为并行集合.同样,任何集合都可以通过调用其seq
上的方法转换为序列集合.
如果集合已经是所请求的类型(并行或串行),则不会进行转换.但是,如果调用seq
并行集合或par
串行集合,将生成具有所请求特征的新集合.
不要混淆seq
,它将集合转换为非并行集合toSeq
,它返回Seq
从集合元素创建的集合.调用toSeq
并行集合将返回一个ParSeq
而不是一个串行集合.
While there are many implementing classes and subtraits, there are some basic traits in the hierarchy, each of which providing more methods or more specific guarantees, but reducing the number of classes that could implement them.
In the following subsections, I'll give a brief description of the main traits and the idea behind them.
This trait is pretty much like trait Traversable
described below, but with the limitation that you can only use it once. That is, any methods called on a TraversableOnce
may render it unusable.
This limitation makes it possible for the same methods to be shared between the collections and Iterator
. This makes it possible for a method that works with an Iterator
but not using Iterator
-specific methods to actually be able to work with any collection at all, plus iterators, if rewritten to accept TraversableOnce
.
Because TraversableOnce
unifies collections and iterators, it does not appear in the previous graphs, which concern themselves only with collections.
At the top of the collection hierarchy is trait Traversable
. Its only abstract operation is
def foreach[U](f: Elem => U)
The operation is meant to traverse all elements of the collection, and apply the given operation f to each element. The application is done for its side effect only; in fact any function result of f is discarded by foreach.
Traversible objects can be finite or infinite. An example of an infinite traversable object is the stream
of natural numbers Stream.from(0)
. The method hasDefiniteSize
indicates whether a collection is possibly
infinite. If hasDefiniteSize
returns true, the collection is certainly finite. If it returns false, the
collection has not been not fully elaborated yet, so it might be infinite or finite.
This class defines methods which can be efficiently implemented in terms of foreach
(over 40 of them).
This trait declares an abstract method iterator
that returns an iterator that yields all the collection’s elements one by one. The foreach
method in Iterable
is implemented in terms of iterator
. Subclasses of Iterable
often override foreach with a direct implementation for efficiency.
Class Iterable
also adds some less-often used methods to Traversable
, which can be implemented efficiently only if an iterator
is available. They are summarized below.
xs.iterator An iterator that yields every element in xs, in the same order as foreach traverses elements. xs takeRight n A collection consisting of the last n elements of xs (or, some arbitrary n elements, if no order is defined). xs dropRight n The rest of the collection except xs takeRight n. xs sameElements ys A test whether xs and ys contain the same elements in the same order
After Iterable
there come three base traits which inherit from it: Seq
, Set
, and Map
. All three have an apply
method and all three implement the PartialFunction
trait, but the meaning of apply
is different in each case.
I trust the meaning of Seq
, Set
and Map
is intuitive. After them, the classes break up in specific implementations that offer particular guarantees with regards to performance, and the methods it makes available as a result of it. Also available are some traits with further refinements, such as LinearSeq
, IndexedSeq
and SortedSet
.
The listing below may be improved. Leave a comment with suggestions and I'll fix it.
Traversable
-- Basic collection class. Can be implemented just with foreach
.
TraversableProxy
-- Proxy for a Traversable
. Just point self
to the real collection.
TraversableView
-- A Traversable with some non-strict methods.
TraversableForwarder
-- Forwards most methods to underlying
, except toString
, hashCode
, equals
, stringPrefix
, newBuilder
, view
and all calls creating a new iterable object of the same kind.
mutable.Traversable
and immutable.Traversable
-- same thing as Traversable
, but restricting the collection type.
Other special-cases Iterable
classes, such as MetaData
, exists.
Iterable
-- A collection for which an Iterator
can be created (through iterator
).
IterableProxy
, IterableView
, mutable
and immutable.Iterable
.
Iterator
-- A trait which is not descendant of Traversable
. Define next
and hasNext
.
CountedIterator
-- An Iterator
defining count
, which returns the elements seen so far.
BufferedIterator
-- Defines head
, which returns the next element without consuming it.
Other special-cases Iterator
classes, such as Source
, exists.
Map
-- An Iterable
of Tuple2
, which also provides methods for retrieving a value (the second element of the tuple) given a key (the first element of the tuple). Extends PartialFunction
as well.
MapProxy
-- A Proxy
for a Map
.
DefaultMap
-- A trait implementing some of Map
's abstract methods.
SortedMap
-- A Map
whose keys are sorted.
immutable.SortMap
immutable.TreeMap
-- A class implementing immutable.SortedMap
.
immutable.Map
immutable.MapProxy
immutable.HashMap
-- A class implementing immutable.Map
through key hashing.
immutable.IntMap
-- A class implementing immutable.Map
specialized for Int
keys. Uses a tree based on the binary digits of the keys.
immutable.ListMap
-- A class implementing immutable.Map
through lists.
immutable.LongMap
-- A class implementing immutable.Map
specialized for Long
keys. See IntMap
.
There are additional classes optimized for an specific number of elements.
mutable.Map
mutable.HashMap
-- A class implementing mutable.Map
through key hashing.
mutable.ImmutableMapAdaptor
-- A class implementing a mutable.Map
from an existing immutable.Map
.
mutable.LinkedHashMap
-- ?
mutable.ListMap
-- A class implementing mutable.Map
through lists.
mutable.MultiMap
-- A class accepting more than one distinct value for each key.
mutable.ObservableMap
-- A mixin which, when mixed with a Map
, publishes events to observers through a Publisher
interface.
mutable.OpenHashMap
-- A class based on an open hashing algorithm.
mutable.SynchronizedMap
-- A mixin which should be mixed with a Map
to provide a version of it with synchronized methods.
mutable.MapProxy
.
Seq
-- A sequence of elements. One assumes a well-defined size and element repetition. Extends PartialFunction
as well.
IndexedSeq
-- Sequences that support O(1) element access and O(1) length computation.
IndexedSeqView
immutable.PagedSeq
-- An implementation of IndexedSeq
where the elements are produced on-demand by a function passed through the constructor.
immutable.IndexedSeq
immutable.Range
-- A delimited sequence of integers, closed on the lower end, open on the high end, and with a step.
immutable.Range.Inclusive
-- A Range
closed on the high end as well.
immutable.Range.ByOne
-- A Range
whose step is 1.
immutable.NumericRange
-- A more generic version of Range
which works with any Integral
.
immutable.NumericRange.Inclusive
, immutable.NumericRange.Exclusive
.
immutable.WrappedString
, immutable.RichString
-- Wrappers which enables seeing a String
as a Seq[Char]
, while still preserving the String
methods. I'm not sure what the difference between them is.
mutable.IndexedSeq
mutable.GenericArray
-- An Seq
-based array-like structure. Note that the "class" Array
is Java's Array
, which is more of a memory storage method than a class.
mutable.ResizableArray
-- Internal class used by classes based on resizable arrays.
mutable.PriorityQueue
, mutable.SynchronizedPriorityQueue
-- Classes implementing prioritized queues -- queues where the elements are dequeued according to an Ordering
first, and order of queueing last.
mutable.PriorityQueueProxy
-- an abstract Proxy
for a PriorityQueue
.
LinearSeq
-- A trait for linear sequences, with efficient time for isEmpty
, head
and tail
.
immutable.LinearSeq
immutable.List
-- An immutable, singlely-linked, list implementation.
immutable.Stream
-- A lazy-list. Its elements are only computed on-demand, but memoized (kept in memory) afterwards. It can be theoretically infinite.
mutable.LinearSeq
mutable.DoublyLinkedList
-- A list with mutable prev
, head
(elem
) and tail
(next
).
mutable.LinkedList
-- A list with mutable head
(elem
) and tail
(next
).
mutable.MutableList
-- A class used internally to implement classes based on mutable lists.
mutable.Queue
, mutable.QueueProxy
-- A data structure optimized for FIFO (First-In, First-Out) operations.
mutable.QueueProxy
-- A Proxy
for a mutable.Queue
.
SeqProxy
, SeqView
, SeqForwarder
immutable.Seq
immutable.Queue
-- A class implementing a FIFO-optimized (First-In, First-Out) data structure. There is no common superclass of both mutable
and immutable
queues.
immutable.Stack
-- A class implementing a LIFO-optimized (Last-In, First-Out) data structure. There is no common superclass of both mutable
immutable
stacks.
immutable.Vector
-- ?
scala.xml.NodeSeq
-- A specialized XML class which extends immutable.Seq
.
immutable.IndexedSeq
-- As seen above.
immutable.LinearSeq
-- As seen above.
mutable.ArrayStack
-- A class implementing a LIFO-optimized data structure using arrays. Supposedly significantly faster than a normal stack.
mutable.Stack
, mutable.SynchronizedStack
-- Classes implementing a LIFO-optimized data structure.
mutable.StackProxy
-- A Proxy
for a mutable.Stack
..
mutable.Seq
mutable.Buffer
-- Sequence of elements which can be changed by appending, prepending or inserting new members.
mutable.ArrayBuffer
-- An implementation of the mutable.Buffer
class, with constant amortized time for the append, update and random access operations. It has some specialized subclasses, such as NodeBuffer
.
mutable.BufferProxy
, mutable.SynchronizedBuffer
.
mutable.ListBuffer
-- A buffer backed by a list. It provides constant time append and prepend, with most other operations being linear.
mutable.ObservableBuffer
-- A mixin trait which, when mixed to a Buffer
, provides notification events through a Publisher
interfaces.
mutable.IndexedSeq
-- As seen above.
mutable.LinearSeq
-- As seen above.
Set
-- A set is a collection that includes at most one of any object.
BitSet
-- A set of integers stored as a bitset.
immutable.BitSet
mutable.BitSet
SortedSet
-- A set whose elements are ordered.
immutable.SortedSet
immutable.TreeSet
-- An implementation of a SortedSet
based on a tree.
SetProxy
-- A Proxy
for a Set
.
immutable.Set
immutable.HashSet
-- An implementation of Set
based on element hashing.
immutable.ListSet
-- An implementation of Set
based on lists.
Additional set classes exists to provide optimized implementions for sets from 0 to 4 elements.
immutable.SetProxy
-- A Proxy
for an immutable Set
.
mutable.Set
mutable.HashSet
-- An implementation of Set
based on element hashing.
mutable.ImmutableSetAdaptor
-- A class implementing a mutable Set
from an immutable Set
.
LinkedHashSet
-- An implementation of Set
based on lists.
ObservableSet
-- A mixin trait which, when mixed with a Set
, provides notification events through a Publisher
interface.
SetProxy
-- A Proxy
for a Set
.
SynchronizedSet
-- A mixin trait which, when mixed with a Set
, provides notification events through a Publisher
interface.
Why the Like classes exist (e.g. TraversableLike)
This was done to achieve maximum code reuse. The concrete generic implementation for classes with a certain structure (a traversable, a map, etc) is done in the Like classes. The classes intended for general consumption, then, override selected methods that can be optmized.
What the companion methods are for (e.g. List.companion)
The builder for the classes, ie, the object which knows how to create instances of that class in a way that can be used by methods like map
, is created by a method in the companion object. So, in order to build an object of type X, I need to get that builder from the companion object of X. Unfortunately, there is no way, in Scala, to get from class X to object X. Because of that, there is a method defined in each instance of X, companion
, which returns the companion object of class X.
While there might be some use for such method in normal programs, its target is enabling code reuse in the collection library.
How I know what implicit objects are in scope at a given point
You aren't supposed to care about that. They are implicit precisely so that you don't need to figure out how to make it work.
These implicits exists to enable the methods on the collections to be defined on parent classes but still return a collection of the same type. For example, the map
method is defined on TraversableLike
, but if you used on a List
you'll get a List
back.
There's a 2.8 collection walk-through by Martin Odersky which should probably be your first reference. It has been supplemented as well with architectural notes, which will be of particular interest to those who want to design their own collections.
The rest of this answer was written way before any such thing existed (in fact, before 2.8.0 itself was released).
You can find a paper about it as Scala SID #3. Other papers in that area should be interesting as well to people interested in the differences between Scala 2.7 and 2.8.
我将从论文中引用,有选择地,并与我的一些想法相辅相成.还有一些图像由Matthias在decodified.com上生成,原始的SVG文件可以在这里找到.
集合类/特征本身实际上,集合有三个特征层次结构:一个用于可变集合,一个用于不可变集合,另一个不对集合做任何假设.
在Scala 2.9中引入了并行,串行和并行并行集合之间的区别.我将在下一节中讨论它们.本节中描述的层次结构仅指非并行集合.
下图显示了Scala 2.8引入的非特定层次结构:
显示的所有元素都是特征.在另外两个层次结构中,还有直接继承特征的类以及可以通过隐式转换为包装类来查看属于该层次结构的类.这些图表的图例可以在它们之后找到.
不可变层次结构的图表:
可变层次结构图:
传说:
这是集合层次结构的缩写ASCII描述,适用于那些看不到图像的人.
Traversable | | Iterable | +------------------+--------------------+ Map Set Seq | | | | +----+----+ +-----+------+ Sorted Map SortedSet BitSet Buffer Vector LinearSeq并行集合
当Scala 2.9引入并行集合时,其中一个设计目标是尽可能无缝地使用它们.用最简单的术语来说,可以用并行的方式替换非并行(串行)集合,并立即获得好处.
但是,由于此之前的所有集合都是串行的,因此许多使用它们的算法都假设并依赖于它们是串行的事实.用这种假设喂入方法的并行集合将失败.因此,上一节中描述的所有层次结构都要求进行串行处理.
创建了两个新的层次结构来支持并行集合.
并行集合层次具有的性状相同的名称,但前面有Par
:ParIterable
,ParSeq
,ParMap
和ParSet
.请注意,没有ParTraversable
,因为任何支持并行访问的集合都能够支持更强的ParIterable
特性.它也没有一些更专业的特征存在于串行层次结构中.整个层次结构位于目录下scala.collection.parallel
.
实现并行的集合类也各不相同,有ParHashMap
和ParHashSet
两个可变和不可变的并行收集,加上ParRange
与ParVector
实施immutable.ParSeq
和ParArray
执行mutable.ParSeq
.
另一个层次也存在,反映串行和并行集合的特点,但有一个前缀Gen
:GenTraversable
,GenIterable
,GenSeq
,GenMap
和GenSet
.这些特征是并行和连续集合的父级.这意味着采用a的方法Seq
无法接收并行集合,但是采用a的方法GenSeq
可以使用串行和并行集合.
鉴于这些层次结构的结构,为Scala 2.8编写的代码与Scala 2.9完全兼容,并要求串行行为.没有被重写,它无法利用并行集合,但所需的更改非常小.
任何集合都可以通过调用par
它上面的方法转换为并行集合.同样,任何集合都可以通过调用其seq
上的方法转换为序列集合.
如果集合已经是所请求的类型(并行或串行),则不会进行转换.但是,如果调用seq
并行集合或par
串行集合,将生成具有所请求特征的新集合.
不要混淆seq
,它将集合转换为非并行集合toSeq
,它返回Seq
从集合元素创建的集合.调用toSeq
并行集合将返回一个ParSeq
而不是一个串行集合.
While there are many implementing classes and subtraits, there are some basic traits in the hierarchy, each of which providing more methods or more specific guarantees, but reducing the number of classes that could implement them.
In the following subsections, I'll give a brief description of the main traits and the idea behind them.
This trait is pretty much like trait Traversable
described below, but with the limitation that you can only use it once. That is, any methods called on a TraversableOnce
may render it unusable.
This limitation makes it possible for the same methods to be shared between the collections and Iterator
. This makes it possible for a method that works with an Iterator
but not using Iterator
-specific methods to actually be able to work with any collection at all, plus iterators, if rewritten to accept TraversableOnce
.
Because TraversableOnce
unifies collections and iterators, it does not appear in the previous graphs, which concern themselves only with collections.
At the top of the collection hierarchy is trait Traversable
. Its only abstract operation is
def foreach[U](f: Elem => U)
The operation is meant to traverse all elements of the collection, and apply the given operation f to each element. The application is done for its side effect only; in fact any function result of f is discarded by foreach.
Traversible objects can be finite or infinite. An example of an infinite traversable object is the stream
of natural numbers Stream.from(0)
. The method hasDefiniteSize
indicates whether a collection is possibly
infinite. If hasDefiniteSize
returns true, the collection is certainly finite. If it returns false, the
collection has not been not fully elaborated yet, so it might be infinite or finite.
This class defines methods which can be efficiently implemented in terms of foreach
(over 40 of them).
This trait declares an abstract method iterator
that returns an iterator that yields all the collection’s elements one by one. The foreach
method in Iterable
is implemented in terms of iterator
. Subclasses of Iterable
often override foreach with a direct implementation for efficiency.
Class Iterable
also adds some less-often used methods to Traversable
, which can be implemented efficiently only if an iterator
is available. They are summarized below.
xs.iterator An iterator that yields every element in xs, in the same order as foreach traverses elements. xs takeRight n A collection consisting of the last n elements of xs (or, some arbitrary n elements, if no order is defined). xs dropRight n The rest of the collection except xs takeRight n. xs sameElements ys A test whether xs and ys contain the same elements in the same order
After Iterable
there come three base traits which inherit from it: Seq
, Set
, and Map
. All three have an apply
method and all three implement the PartialFunction
trait, but the meaning of apply
is different in each case.
I trust the meaning of Seq
, Set
and Map
is intuitive. After them, the classes break up in specific implementations that offer particular guarantees with regards to performance, and the methods it makes available as a result of it. Also available are some traits with further refinements, such as LinearSeq
, IndexedSeq
and SortedSet
.
The listing below may be improved. Leave a comment with suggestions and I'll fix it.
Traversable
-- Basic collection class. Can be implemented just with foreach
.
TraversableProxy
-- Proxy for a Traversable
. Just point self
to the real collection.
TraversableView
-- A Traversable with some non-strict methods.
TraversableForwarder
-- Forwards most methods to underlying
, except toString
, hashCode
, equals
, stringPrefix
, newBuilder
, view
and all calls creating a new iterable object of the same kind.
mutable.Traversable
and immutable.Traversable
-- same thing as Traversable
, but restricting the collection type.
Other special-cases Iterable
classes, such as MetaData
, exists.
Iterable
-- A collection for which an Iterator
can be created (through iterator
).
IterableProxy
, IterableView
, mutable
and immutable.Iterable
.
Iterator
-- A trait which is not descendant of Traversable
. Define next
and hasNext
.
CountedIterator
-- An Iterator
defining count
, which returns the elements seen so far.
BufferedIterator
-- Defines head
, which returns the next element without consuming it.
Other special-cases Iterator
classes, such as Source
, exists.
Map
-- An Iterable
of Tuple2
, which also provides methods for retrieving a value (the second element of the tuple) given a key (the first element of the tuple). Extends PartialFunction
as well.
MapProxy
-- A Proxy
for a Map
.
DefaultMap
-- A trait implementing some of Map
's abstract methods.
SortedMap
-- A Map
whose keys are sorted.
immutable.SortMap
immutable.TreeMap
-- A class implementing immutable.SortedMap
.
immutable.Map
immutable.MapProxy
immutable.HashMap
-- A class implementing immutable.Map
through key hashing.
immutable.IntMap
-- A class implementing immutable.Map
specialized for Int
keys. Uses a tree based on the binary digits of the keys.
immutable.ListMap
-- A class implementing immutable.Map
through lists.
immutable.LongMap
-- A class implementing immutable.Map
specialized for Long
keys. See IntMap
.
There are additional classes optimized for an specific number of elements.
mutable.Map
mutable.HashMap
-- A class implementing mutable.Map
through key hashing.
mutable.ImmutableMapAdaptor
-- A class implementing a mutable.Map
from an existing immutable.Map
.
mutable.LinkedHashMap
-- ?
mutable.ListMap
-- A class implementing mutable.Map
through lists.
mutable.MultiMap
-- A class accepting more than one distinct value for each key.
mutable.ObservableMap
-- A mixin which, when mixed with a Map
, publishes events to observers through a Publisher
interface.
mutable.OpenHashMap
-- A class based on an open hashing algorithm.
mutable.SynchronizedMap
-- A mixin which should be mixed with a Map
to provide a version of it with synchronized methods.
mutable.MapProxy
.
Seq
-- A sequence of elements. One assumes a well-defined size and element repetition. Extends PartialFunction
as well.
IndexedSeq
-- Sequences that support O(1) element access and O(1) length computation.
IndexedSeqView
immutable.PagedSeq
-- An implementation of IndexedSeq
where the elements are produced on-demand by a function passed through the constructor.
immutable.IndexedSeq
immutable.Range
-- A delimited sequence of integers, closed on the lower end, open on the high end, and with a step.
immutable.Range.Inclusive
-- A Range
closed on the high end as well.
immutable.Range.ByOne
-- A Range
whose step is 1.
immutable.NumericRange
-- A more generic version of Range
which works with any Integral
.
immutable.NumericRange.Inclusive
, immutable.NumericRange.Exclusive
.
immutable.WrappedString
, immutable.RichString
-- Wrappers which enables seeing a String
as a Seq[Char]
, while still preserving the String
methods. I'm not sure what the difference between them is.
mutable.IndexedSeq
mutable.GenericArray
-- An Seq
-based array-like structure. Note that the "class" Array
is Java's Array
, which is more of a memory storage method than a class.
mutable.ResizableArray
-- Internal class used by classes based on resizable arrays.
mutable.PriorityQueue
, mutable.SynchronizedPriorityQueue
-- Classes implementing prioritized queues -- queues where the elements are dequeued according to an Ordering
first, and order of queueing last.
mutable.PriorityQueueProxy
-- an abstract Proxy
for a PriorityQueue
.
LinearSeq
-- A trait for linear sequences, with efficient time for isEmpty
, head
and tail
.
immutable.LinearSeq
immutable.List
-- An immutable, singlely-linked, list implementation.
immutable.Stream
-- A lazy-list. Its elements are only computed on-demand, but memoized (kept in memory) afterwards. It can be theoretically infinite.
mutable.LinearSeq
mutable.DoublyLinkedList
-- A list with mutable prev
, head
(elem
) and tail
(next
).
mutable.LinkedList
-- A list with mutable head
(elem
) and tail
(next
).
mutable.MutableList
-- A class used internally to implement classes based on mutable lists.
mutable.Queue
, mutable.QueueProxy
-- A data structure optimized for FIFO (First-In, First-Out) operations.
mutable.QueueProxy
-- A Proxy
for a mutable.Queue
.
SeqProxy
, SeqView
, SeqForwarder
immutable.Seq
immutable.Queue
-- A class implementing a FIFO-optimized (First-In, First-Out) data structure. There is no common superclass of both mutable
and immutable
queues.
immutable.Stack
-- A class implementing a LIFO-optimized (Last-In, First-Out) data structure. There is no common superclass of both mutable
immutable
stacks.
immutable.Vector
-- ?
scala.xml.NodeSeq
-- A specialized XML class which extends immutable.Seq
.
immutable.IndexedSeq
-- As seen above.
immutable.LinearSeq
-- As seen above.
mutable.ArrayStack
-- A class implementing a LIFO-optimized data structure using arrays. Supposedly significantly faster than a normal stack.
mutable.Stack
, mutable.SynchronizedStack
-- Classes implementing a LIFO-optimized data structure.
mutable.StackProxy
-- A Proxy
for a mutable.Stack
..
mutable.Seq
mutable.Buffer
-- Sequence of elements which can be changed by appending, prepending or inserting new members.
mutable.ArrayBuffer
-- An implementation of the mutable.Buffer
class, with constant amortized time for the append, update and random access operations. It has some specialized subclasses, such as NodeBuffer
.
mutable.BufferProxy
, mutable.SynchronizedBuffer
.
mutable.ListBuffer
-- A buffer backed by a list. It provides constant time append and prepend, with most other operations being linear.
mutable.ObservableBuffer
-- A mixin trait which, when mixed to a Buffer
, provides notification events through a Publisher
interfaces.
mutable.IndexedSeq
-- As seen above.
mutable.LinearSeq
-- As seen above.
Set
-- A set is a collection that includes at most one of any object.
BitSet
-- A set of integers stored as a bitset.
immutable.BitSet
mutable.BitSet
SortedSet
-- A set whose elements are ordered.
immutable.SortedSet
immutable.TreeSet
-- An implementation of a SortedSet
based on a tree.
SetProxy
-- A Proxy
for a Set
.
immutable.Set
immutable.HashSet
-- An implementation of Set
based on element hashing.
immutable.ListSet
-- An implementation of Set
based on lists.
Additional set classes exists to provide optimized implementions for sets from 0 to 4 elements.
immutable.SetProxy
-- A Proxy
for an immutable Set
.
mutable.Set
mutable.HashSet
-- An implementation of Set
based on element hashing.
mutable.ImmutableSetAdaptor
-- A class implementing a mutable Set
from an immutable Set
.
LinkedHashSet
-- An implementation of Set
based on lists.
ObservableSet
-- A mixin trait which, when mixed with a Set
, provides notification events through a Publisher
interface.
SetProxy
-- A Proxy
for a Set
.
SynchronizedSet
-- A mixin trait which, when mixed with a Set
, provides notification events through a Publisher
interface.
Why the Like classes exist (e.g. TraversableLike)
This was done to achieve maximum code reuse. The concrete generic implementation for classes with a certain structure (a traversable, a map, etc) is done in the Like classes. The classes intended for general consumption, then, override selected methods that can be optmized.
What the companion methods are for (e.g. List.companion)
The builder for the classes, ie, the object which knows how to create instances of that class in a way that can be used by methods like map
, is created by a method in the companion object. So, in order to build an object of type X, I need to get that builder from the companion object of X. Unfortunately, there is no way, in Scala, to get from class X to object X. Because of that, there is a method defined in each instance of X, companion
, which returns the companion object of class X.
While there might be some use for such method in normal programs, its target is enabling code reuse in the collection library.
How I know what implicit objects are in scope at a given point
You aren't supposed to care about that. They are implicit precisely so that you don't need to figure out how to make it work.
These implicits exists to enable the methods on the collections to be defined on parent classes but still return a collection of the same type. For example, the map
method is defined on TraversableLike
, but if you used on a List
you'll get a List
back.