summaryrefslogtreecommitdiff
path: root/src/library/scala/collection/mutable/LinkedList.scala
Commit message (Collapse)AuthorAgeFilesLines
* Lower-case spelling of @deprecated messagesSimon Ochsenreither2016-05-281-2/+2
|
* Fix many typos in docs and commentsmpociecha2014-12-141-1/+1
| | | | | | | | | | | | | This commit corrects many typos found in scaladocs, comments and documentation. It should reduce a bit number of PRs which fix one typo. There are no changes in the 'real' code except one corrected name of a JUnit test method and some error messages in exceptions. In the case of typos in other method or field names etc., I just skipped them. Obviously this commit doesn't fix all existing typos. I just generated in IntelliJ the list of potential typos and looked through it quickly.
* Collections library tidying and deprecation. Separate parts are listed below.Rex Kerr2013-11-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Absolutized paths involving the scala package.Paul Phillips2013-05-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Confusing, now-it-happens now-it-doesn't mysteries lurk in the darkness. When scala packages are declared like this: package scala.collection.mutable Then paths relative to scala can easily be broken via the unlucky presence of an empty (or nonempty) directory. Example: // a.scala package scala.foo class Bar { new util.Random } % scalac ./a.scala % mkdir util % scalac ./a.scala ./a.scala:4: error: type Random is not a member of package util new util.Random ^ one error found There are two ways to play defense against this: - don't use relative paths; okay sometimes, less so others - don't "opt out" of the scala package This commit mostly pursues the latter, with occasional doses of the former. I created a scratch directory containing these empty directories: actors annotation ant api asm beans cmd collection compat concurrent control convert docutil dtd duration event factory forkjoin generic hashing immutable impl include internal io logging macros man1 matching math meta model mutable nsc parallel parsing partest persistent process pull ref reflect reify remote runtime scalap scheduler script swing sys text threadpool tools transform unchecked util xml I stopped when I could compile the main src directories even with all those empties on my classpath.
* Brings all copyrights (in comments) up-to-date, from 2011/12 to 2013Heather Miller2012-11-021-1/+1
|
* Fixes SI-4478.Simon Ochsenreither2012-05-021-2/+2
| | | | | | | | | | - Replaced/simplified usages of "wrt". - Added backticks to $Coll definitions, so stuff like "immutable.Stack" hopefully stops being interpreted as the end of a sentence and shown like that in the summary line of ScalaDoc's method description. See collection.immutable.Stack's sortBy. Additionally, it looks nicer this way. - Fixes the typo mentioned in SI-5666.
* Update scaladoc links to collections overview.Josh Marcus2011-12-061-1/+1
| | | | | | Change scaladoc links in collection classes to point at re-formatted Collections Overview on docs.scala-lang.org. Fix minor typo: s/Ummutable/Immutable
* Enhanced scaladoc of collection classes with links to the relevant pages of ↵Josh Marcus2011-12-051-0/+2
| | | | "The Scala 2.8 Collections API" overview.
* Dropped about 1.5 Mb off scala-library.jar.Paul Phillips2011-11-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit and the two subsequent commits were contributed by: Todd Vierling <tv@duh.org>. I combined some commits and mangled his commit messages, but all the credit is his. This pursues the same approach to classfile reduction seen in r19989 when AbstractFunctionN was introduced, but applies it to the collections. Thanks to -Xlint it's easy to verify that the private types don't escape. Design considerations as articulated by Todd: * Don't necessarily create concrete types for _everything_. Where a subtrait only provides a few additional methods, don't bother; instead, use the supertrait's concrete class and retain the "with". For example, "extends AbstractSeq[A] with LinearSeq[A]". * Examine all classes with .class file size greater than 10k. Named classes and class names ending in $$anon$<num> are candidates for analysis. * If a return type is currently inferred where an anon subclass would be returned, make the return type explicit. Don't allow the library-private abstract classes to leak into the public namespace [and scaladoc].
* - Update Scaladoc for LinkedList and for some o...Paul Phillips2011-07-291-24/+74
| | | | | | | | | | - Update Scaladoc for LinkedList and for some of the functions/operators - that it inherits. Completed Scaladoc for append Added example - in GenSeqLike for apply. Added $collectExample to collect in - GenTraversableLike and supplied an actual example in LinkedList Contributed by Donald McLean.
* Discovered another impressive source of unneces...Paul Phillips2011-07-041-1/+1
| | | | | | | | | | Discovered another impressive source of unnecessary garbage is every collection creating a new GenericCanBuildFrom for every map ever performed. They can all use the same one: they all have the same implementation. It looks like tiark had already figured this out and done it for Vector: I followed with the other fifty. I really haven't the least idea who to have review most things. No review.
* A bunch of scaladoc cleanups.Paul Phillips2011-03-291-1/+1
| | | | | | | | the wrong places, tags saying the wrong thing. I sorted types and values so deprecated ones are at the end. I think they should be hidden by default, but this is a big improvement. Leaving #3914 open so they can be made invisible. No review.
* Fix for linked lists closes #4080 and proves my...Paul Phillips2011-03-271-2/+1
| | | | | | | | | | | | | | | | | | | | | | | Fix for linked lists closes #4080 and proves my desire not to ship obviously broken code is even greater than my will to hold out for any help. I threw in a free fix for this which I noticed while in there. scala> scala.collection.mutable.LinkedList[Int]().head res0: Int = 0 Also was reminded how useless tests can be: val ten = DoubleLinkedList(1 to 10: _*) ten.insert(DoubleLinkedList(11)) // Post-insert position test require(ten.last == 11) Fortunately a test confirming buggy behavior still serves a purpose by breaking when you fix the bug which allowed it to pass, thus letting you fix the broken test too. Life's (very) little compensations. Linked list code should still be presumed broken. No review.
* Updated copyright notices to 2011Antonio Cunei2011-01-201-1/+1
|
* Deprecated the @serializable annotation, introd...Lukas Rytz2010-11-301-2/+3
| | | | | | | | | | | | | | | | | | | Deprecated the @serializable annotation, introduce a new trait "scala.Serializable" which has to be extended instead (cross-platform). Known issues: - Companion objects of serializable classes (including case classes) are automatically made serializable. However, they don't extend "Serializable" statically because of the known difficulty (should be done before typing, but hard). - Writing "case class C() extends Serializable" gives "error: trait Serializable is inherited twice" - Functions are serializable, but don't extend Serializable dynamically (could be fixed by making FunctionN Serializable - shouldn't we?) Note that @SerialVersionUID continues to be an annotation; it generates a static field, which is not possible otherwise in scala. Review by dragos, extempore. Question to dragos: in JavaPlatform.isMaybeBoxed, why is there a test for "JavaSerializableClass"? Is that correct?
* Removed more than 3400 svn '$Id' keywords and r...Antonio Cunei2010-05-121-1/+0
| | | | | Removed more than 3400 svn '$Id' keywords and related junk.
* Docs. No review.Aleksandar Pokopec2010-04-101-2/+22
|
* Updated copyright notices to 2010Antonio Cunei2009-12-071-1/+1
|
* updated/extended serialization tests michelou2009-11-201-1/+1
|
* Changed the ctor of the LinkedList so that it i...Aleksandar Pokopec2009-11-101-2/+4
| | | | | | Changed the ctor of the LinkedList so that it ignores null if given as the next list.
* tentative re-implementation of LinkedList and s...Martin Odersky2009-11-101-5/+14
| | | | | tentative re-implementation of LinkedList and subclasses
* removed some of the code duplication that Marti...Adriaan Moors2009-10-221-4/+1
| | | | | removed some of the code duplication that Martin pointed out in my addition of def apply() to GenericCanBuildFrom
* renamed BuilderFactory[El, To, From] -> CanBuil...Adriaan Moors2009-10-211-2/+4
| | | | | | | | | | | | | | | | | | | | | renamed BuilderFactory[El, To, From] -> CanBuildFrom[From, El, To] and added apply() overload to create collections from scratch generically added def apply() overload to BuilderFactory so that we can also create collections from scratch generically (see test test/files/pos/collectGenericCC.scala) renaming: - BuilderFactory[El, To, From] -> CanBuildFrom[From, El, To] bulk type-param reordering using: s/CanBuildFrom\[\s*([^,()\s]*)\s*,(\s+[^\s,()]*)\s*,\s+([^\s,()]*)\s*\]/CanBuildFrom[$3, $1,$2]/ some argument lists got mixed up because they contained 4 comma's... - builderFactory -> canBuildFrom removed explicit implicit value in DocDriver that was renamed renamed collection/generic/BuilderFactory.scala -> collection/generic/CanBuildFrom.scala tested with clean build using ant strap.done -- everything went well on my machine
* Sequence->SeqMartin Odersky2009-10-021-2/+2
|
* add @since annotationsstepancheg2009-09-261-0/+1
|
* Collections refactoring.Martin Odersky2009-09-251-5/+6
|
* fixed headers/comments/svn props, made some pro...michelou2009-09-151-5/+4
| | | | | | fixed headers/comments/svn props, made some progress with serializable classes
* switch to unnested packages.Martin Odersky2009-07-241-1/+1
|
* cleaned up collection builder frameworkMartin Odersky2009-05-141-5/+5
|
* Removed redundant type parameter for class Buil...Martin Odersky2009-05-091-2/+2
| | | | | Removed redundant type parameter for class Builder
* 4 out of 5 spelling bee champs say: TraversablePaul Phillips2009-05-081-2/+2
|
* massive new collections checkin.Martin Odersky2009-05-081-25/+16
|
* Updated copyright notices to 2009Antonio Cunei2009-01-091-1/+1
|
* fixed #551 and #566michelou2008-02-261-1/+14
|
* fixed problems in subtyping.Martin Odersky2007-07-241-3/+4
| | | | | fixed unsafe isInstanceOf's
* updated annotations in Scala librarymichelou2007-02-201-3/+3
|
* removed leading/trailing tabs/blanks in collect...michelou2006-10-041-6/+5
| | | | | removed leading/trailing tabs/blanks in collection/mutable/*.scala
* undid import Predef._, after resolving dependen...Burak Emir2006-03-251-2/+0
| | | | | undid import Predef._, after resolving dependency in TopScope.
* undid consolidation in object XML, and added im...Burak Emir2006-03-251-0/+1
| | | | | | undid consolidation in object XML, and added import Predef._ to all files that needed it. strange.
* Small refactoring in some collection classesmihaylov2006-03-031-3/+1
|
* Rearranged header and updated copyright messagemihaylov2006-03-021-2/+5
|
* Switching to the new build system and to the ne...Gilles Dubochet2005-12-191-0/+34
Switching to the new build system and to the new build system. This is a MAJOR commit, so be careful when updating.