| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
For Range and NumericRange, toString will indicate the step
if it is not 1.
Additionally, indicate empty ranges and ranges which are not
"exact".
For a "mapped" range, used by `Range.Double`, toString
includes the underlying range and the simple type of the step
(to distinguish Double from BigDecimal).
|
|
|
|
| |
ListSet and ListMap are two collections which share the exact same internal structure. This commit makes the two approaches as similar as possible by renaming and reordering internal methods, improving their Scaladoc and their code style. The Scaladoc of the classes and companion objects is also improved in order to alert users of the time complexity of the collections' operations.
|
|
|
|
|
|
|
|
| |
Makes the immutable `ListMap` and `ListSet` collections more alike one another, both in their semantics and in their performance.
In terms of semantics, makes the `ListSet` iterator return the elements in their insertion order, as `ListMap` already does. While, as mentioned in SI-8985, `ListMap` and `ListSet` doesn't seem to make any guarantees in terms of iteration order, I believe users expect `ListSet` and `ListMap` to behave in the same way, particularly when they are implemented in the exact same way.
In terms of performance, `ListSet` has a custom builder that avoids creation in O(N^2) time. However, this significantly reduces its performance in the creation of small sets, as its requires the instantiation and usage of an auxilliary HashSet. As `ListMap` and `ListSet` are only suitable for small sizes do to their performance characteristics, the builder is removed, the default `SetBuilder` being used instead.
|
|
|
|
|
| |
Mark method as deprecated due to it not providing the expected result,
while fixing it will break existing code.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Collections library tidying, part one: scripting.
Everything in scala.collection.scripting is deprecated now, along with the
<< method that is implemented in a few other classes. Scripting does not
seem used at all, and anyone who did can easily write a wrapper that does
the same thing.
Deprecated *Proxy collections.
The only place proxies were used in the library was in swing.ListView, and
that was easy to change to a lazy val.
Proxy itself is used in ScalaNumberProxy and such, so it was left
undeprecated.
Deprecated Synchronized* traits from collections.
Synchronizability does not compose well, and it requires careful examination
of every method (which has not actually been done).
Places where the Scala codebase needs to be fixed (eventually) include:
scala.reflect.internal.util.Statistics$QuantMap
scala.tools.nsc.interactive.Global (several places)
Deprecated LinkedList (including Double- and -Like variants).
Interface is idiosyncratic and dangerously low-level. Although some
low-level functionality of this sort would be useful, this doesn't seem
to be the ideal implementation.
Also deprecated the extractFirst method in Queue as it exposes LinkedList.
Cannot shift internal representations away from LinkedList at this time
because of that method.
Deprecated non-finality of several toX collection methods.
Improved documentation of most toX collection methods to describe what the
expectation is for their behavior. Additionally deprecated overriding of
- toIterator in IterableLike (should always forward to iterator)
- toTraversable in TraversableLike (should always return self)
- toIndexedSeq in immutable.IndexedSeq (should always return self)
- toMap in immutable.Map (should always return self)
- toSet in immutable.Set (should always return self)
Did not do anything with IterableLike.toIterable or Seq/SeqLike.toSeq since
for some odd reason immutable.Range overrides those.
Deprecated Forwarders from collections.
Forwarding, without an automatic mechanism to keep up to date with changes
in the forwarded class, is inherently unreliable. Absent a mechanism to
keep current, they're deprecated. ListBuffer is the only class in the
collections library that uses forwarders, and that functionality can be
rolled into ListBuffer itself.
Deprecating immutable set/map adaptors.
They're a bad idea (barring compiler support) for the same reason that all
the other adaptors are a bad idea: they get out of date and probably have a
variety of performance bugs.
Deprecated inheritance from leaf classes in immutable collections.
Inheriting from leaf-classes in immutable collections is rarely a good idea
since whenever you use any interesting collections method you'll revert to
the original class. Also, the methods are often designed to work with only
particular behavior, and an override would be difficult (at best) to make
work. Fortunately, people seem to have realized this and there are few to
no cases of people extending PagedSeq and TreeSet and the like.
Note that in many cases the classes will become sealed not final.
Deprecated overriding of methods and inheritance from various mutable
collections.
Some mutable collections seem unsuited for overriding since to override
anything interesting you would need vast knowledge of internal data
structures and/or access to private methods. These include
- ArrayBuilder.ofX classes.
- ArrayOps
- Some methods of BitSet (moved others from private to protected final)
- Some methods of HashTable and FlatHashTable
- Some methods of HashMap and HashSet (esp += and -= which just forward)
- Some methods of other maps and sets (LinkedHashX, ListMap, TreeSet)
- PriorityQueue
- UnrolledBuffer
This is a somewhat aggressive deprecation, the theory being better to try it
out now and back off if it's too much than not attempt the change and be
stuck with collections that can neither be safely inherited nor have
implementation details changed.
Note that I have made no changes--in this commit--which would cause
deprecation warnings in any of the Scala projects available on Maven (at
least as gathered by Adriaan). There are deprecation warnings induced
within the library (esp. for classes/traits that should become static) and
the compiler. I have not attempted to fix all the deprecations in the
compiler as some of them touch the IDE API (but these mostly involved
Synchronized which is inherently unsafe, so this should be fixed
eventually in coordination with the IDE code base(s)).
Updated test checks to include new deprecations.
Used a higher level implementation for messages in JavapClass.
|
|
|
|
|
|
|
|
|
| |
Every test deleted here has found its way to the respective
repositories of scala-xml and scala-parser-combinators,
where they will continue to be tested with partest.
The modified tests became independent of these modules,
as they should've been from the start.
|
| |
|
|
|
|
|
|
|
|
| |
Introduced the collection.concurrent package and introduced the
concurrent.Map trait there. Deprecated the mutable.ConcurrentMap trait.
Pending work - introduce the appropriate changes to JavaConversions
and JavaConverters.
|
| |
|
|
|
|
| |
This fix was previously only applied to hash sets.
|
|
|
|
| |
Changed parameters in some tests to speed them up.
|
|
|
|
| |
Implemented Ctrie serialization. Improved hashcode computation.
|
| |
|
|
|
|
|
|
|
| |
This implementation is based on AVL trees.
The current implementation is contributed by Lucien Pereira.
Fixes #4147.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The hash code is further improved by using a special value in the hash sets
called a `seed`. For sequential hash tables, this value depends on the size
of the hash table. It determines the number of bits the hashcode should be
rotated. This ensures that hash tables with different sizes use different
bits to compute the position of the element. This way traversing the elements
of the source hash table will yield them in the order where they had similar
hashcodes (and hence, positions) in the source table, but different ones in
the destination table.
Ideally, in the future we want to be able to have a family of hash functions
and assign a different hash function from that family to each hash table
instance. That would statistically almost completely eliminate the possibility
that the hash table element traversal causes excessive collisions.
I should probably @mention extempore here.
|
|
|
|
|
|
|
| |
Removing the code which has been deprecated since 2.8.0. Contributed by
Simon Ochsenreither, although deleting code is such fun one hesitates to
call it a contribution. Still, we will. Closes SI-4860, no review.
|
|
|
|
|
|
|
|
| |
Revert "Added missing string prefixes for names of map and set
collection classes." and related commits.
No review.
|
|
|
|
|
|
|
|
| |
Another fix for a broken test case involving new set and map string
reps.
No review.
|
|
|
|
|
| |
Fixing tests depending on map and set string representations. No review.
|
|
|
|
|
| |
No review.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Added separate bitmaps for private and transient lazy vals. Closes
#3038, #1573. Review by dragos. I had to fix a couple of initialization
issues that checkinit forced me to do and that weren't a problem before
because the bitmap was serialized even for @transitive. For that I
needed to change the setters in checkinit so that they also update the
bitmap.
|
|
|
|
|
| |
No review.
|
|
|
|
|
| |
As hash codes change, so do the tests - output order for a HashMap is different now. No review.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some tweaks to ListSet to make it less pathological in its outlook. We
can see some modest improvements in run time and answer quality via the
enclosed test case:
// with this patch: 2.250s elapsed, assertions pass.
// without this patch: 51.441s elapsed, and it's
a mercy killing: java.lang.StackOverflowError at
scala.collection.immutable.ListSet$Node.contains(ListSet.scala:117) at
scala.collection.immutable.ListSet$Node.contains(ListSet.scala:117)
Closes #3822, review by community.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
- new immutable HashMap implementation based on a hash trie. this is the
first iteration, more optimizations will be added later. - updated test
cases to reflect new ordering of elements - made Map.empty and Set.empty
singletons, deprecating classes Map.EmptyMap and Set.EmptySet Review by
extempore, odersky.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[This patch submitted by ismael juma - commit message his words,
but condensed.]
Fix ticket #1600: Serialization and deserialization of hash-based
collections should not re-use hashCode. The collection is rebuilt
on deserialization - note that this is not compatible with the previous
serialization format. All @SerialVersionUIDs have been reset to 1.
WeakHashMap is not Serializable and should not be so. TreeHashMap has
not been reintegrated yet. OpenHashMap has not been updated. (I think
this collection is flawed and should be removed or reimplemented.)
|
| |
|
|
|
|
|
|
| |
Fixed collections unit test (regression in ListBuffer.apply) and
serialization test.
|
|
|
|
|
|
| |
Moved disabled tests back into their original place. Expect 7 tests to
fail.
|
| |
|
|
|
|
|
|
| |
Modifications to the 10 failing test cases to make them passing test
cases in light of the patch from #1118.
|
|
|
|
|
| |
add serialization test, disabled patmat debug traces
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
case classes now generate objects not factory methods. some small
cleanups for type inference
|
|
|
|
|
| |
Moved tests that are failing, but no present fixes into pending.
|