summaryrefslogtreecommitdiff
path: root/src/library/scala/collection/GenMapLike.scala
Commit message (Collapse)AuthorAgeFilesLines
* SI-6947 Better type parameter names for Map classesStefan Zeiger2016-07-071-18/+18
| | | | | | | | | | | | | | | | | | | | Type parameter names are currently assigned pretty much alphabetically without any meaning. This change renames all key parameters in Map classes from `A` to `K` and all value parameters from `B` to `V` to make them more meaningful. Derived names are renamed accordingly (e.g. `V1` instead of `B1` for an upper bound on `V`, `W` instead of `C` for a new value type). As a side-effect this solves the documentation problem in SI-6947. Due to using `B` both as a type parameter for `foldLeft[B]` in `GenTraversableOnce[A]` and in `Map[A, B]` which extends `GenTraversableOnce[(A, B)]`, the signature of `Map.foldLeft` was rendered in scaladoc as def foldLeft[B](z: B)(op: (B, (A, B)) ⇒ B): B Now you get an unambiguous version: def foldLeft[B](z: B)(op: (B, (K, V)) ⇒ B): B
* Remove two lingering `println`s in non-debug methods of the library.Sébastien Doeraene2015-10-131-2/+1
|
* [backport] Fixes cut sentences in the generated scaladocsDominik Gruntz2014-08-111-1/+1
| | | | | | | | | | | | | | | | | This commit changes all first sentences of library functions which contain `i.e.` or `e.g.` and adds a `,` to prevent that the scaladoc summary sentence is cut after this abbreviation. This is possible as pull/3824 fixed how Scaladoc parses the first sentence of a method description into a sumary sentence(now the first sentence has to end with a dot followed by whitespace). Only docs in the core library are changed (src/library/**/*.scala) and only if they occur in the first sentence. Review by @heathermiller (cherry picked from commit 72721ff5dd06dea1235ecb71acae0bd61aee4814)
* 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
|
* More relative path elimination.Paul Phillips2012-09-151-1/+1
| | | | | | | | | | | | | | | | Some names I missed in 55b609458fd . How one might know when one is done: mkdir scratch && cd scratch mkdir annotation beans collection compat concurrent io \ math parallel ref reflect runtime scala sys testing \ text tools util xml scalac $(find ../src/library -name '*.scala') Until recently that would fail with about a billion errors. When it compiles, that's when you're done. And that's where this commit takes us, for src/library at least.
* Add the first iteration of the `util.hashing` package.Aleksandar Prokopec2012-06-071-1/+1
| | | | | | | | | | | | | | | | | Move `MurmurHash3` to `util.hashing`. Make the `class` private and retain a public companion `object`, and put the `MurmurHash3.Hashing` implementations for various types in the companion. Add a method which composes `ByteswapHashing` with some other hashing. Rename `hashOf` to `hash`. Fix chi-square test in a test-case. Review by @jsuereth. Moved a failing test that seems to use some other library version to pending.
* Address doc comment rot in the standard library.Jason Zaugg2012-05-131-1/+0
| | | | | | | | | | | | | | | | | | | | | - Match @param/@tparam names to the actual parameter name - Use @tparam for type parameters - Whitespace is required between `*` and `@` - Fix incorrect references to @define macros. - Use of monospace `` and {{{}}} (much more needed) - Remove `@param p1 ...` stubs, which appear in the generated docss. - But, retainsed `@param p1` stubs, assuming they will be filtered from the generated docs by SI-5795. - Avoid use of the shorthand `@param doc for the solitary param` (which works, but isn't recognized by the code inspection in IntelliJ I used to sweep through the problems) The remaining warnings from `ant docs` seem spurious, I suspect they are an unintended consequence of documenting extension methods. [scaladoc] /Users/jason/code/scala/src/library/scala/collection/TraversableOnce.scala:181: warning: Variable coll undefined in comment for method reduceOption in class Tuple2Zipped [scaladoc] def reduceOption[A1 >: A](op: (A1, A1) => A1): Option[A1] = reduceLeftOption(op) [scaladoc] ^
* Fixes SI-4478.Simon Ochsenreither2012-05-021-1/+1
| | | | | | | | | | - 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.
* Adapted usecases to full signature displayVlad Ureche2012-03-201-0/+2
|
* Refinements of "def seq" and murmurhash.Paul Phillips2011-11-241-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Trying to make hashcodes faster. Didn't achieve much on that front, so redirected into structural/consistency issues. The latter was lacking in terms of how/where "def seq" was defined. The documentation I can find doesn't give me much hint that the sequential form of my sequential collection might be a single-use iterator! (As in StringOps, ArrayOps.) If that's intentional it should be in huge letters. I'm assuming for now that it wasn't. Also, there was this: GenMapLike: def seq: Map[A, B] GenSetLike: def seq: Set[A] GenSeqLike: // nothing, returns Traversable So I added some def seqs where I needed the more specific types for my hashcode work. Hashcodewise, I broke the MurmurHash3 object into a reusable class and a collections-specific object, and I deprecated the methods which took GenTraversableOnce in favor of ones taking TraversableOnce, because there's no reason the hashcode library should have to know about things like "make sure to call seq before you traverse or you'll be sorry." Exclude things by their type and you can never make a mistake. End transmission.
* Refinement of murmurhash implementation.Paul Phillips2011-09-081-1/+1
| | | | | | Integrates recent speed improvements to algorithm. Contributed by Ruediger Keller, no review.
* Adding the missing ParMap and GenMap methods.Aleksandar Pokopec2011-07-261-0/+68
| | | | | No review.
* Removing the package-private modifiers on Gen*L...Aleksandar Pokopec2011-06-221-1/+1
| | | | | | | Removing the package-private modifiers on Gen*Like traits. No review.
* Adding some docs refactorings.Aleksandar Pokopec2011-04-141-1/+7
| | | | | | | Also, added some docs variables to Gen* traits that were missing. No review.
* Doing a little polishing on the parallel collec...Paul Phillips2011-04-141-5/+2
| | | | | | | | | | | | | Doing a little polishing on the parallel collections refactor (which overall looks like a big improvement.) I went for some simpler wording and moved a number of scaladoc tags around because the rug had been pulled out from under their feet. This leaves a lot undone, but since many of the docs need to be reworded before they can move from e.g. SeqLike to GenSeqLike, and I'm not well informed on exactly how these abstractions are being presented, I stayed in the safe zone. Review by prokopec.
* Refactoring the collections api to support diff...Aleksandar Pokopec2011-04-131-0/+61
Refactoring the collections api to support differentiation between referring to a sequential collection and a parallel collection, and to support referring to both types of collections. New set of traits Gen* are now superclasses of both their * and Par* subclasses. For example, GenIterable is a superclass of both Iterable and ParIterable. Iterable and ParIterable are not in a subclassing relation. The new class hierarchy is illustrated below (simplified, not all relations and classes are shown): TraversableOnce --> GenTraversableOnce ^ ^ | | Traversable --> GenTraversable ^ ^ | | Iterable --> GenIterable <-- ParIterable ^ ^ ^ | | | Seq --> GenSeq <-- ParSeq (the *Like, *View and *ViewLike traits have a similar hierarchy) General views extract common view functionality from parallel and sequential collections. This design also allows for more flexible extensions to the collections framework. It also allows slowly factoring out common functionality up into Gen* traits. From now on, it is possible to write this: import collection._ val p = parallel.ParSeq(1, 2, 3) val g: GenSeq[Int] = p // meaning a General Sequence val s = g.seq // type of s is Seq[Int] for (elem <- g) { // do something without guarantees on sequentiality of foreach // this foreach may be executed in parallel } for (elem <- s) { // do something with a guarantee that foreach is executed in order, sequentially } for (elem <- p) { // do something concurrently, in parallel } This also means that some signatures had to be changed. For example, method `flatMap` now takes `A => GenTraversableOnce[B]`, and `zip` takes a `GenIterable[B]`. Also, there are mutable & immutable Gen* trait variants. They have generic companion functionality.