| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit 'refs/pull/1574/head': (24 commits)
Fixing issue where OSGi bundles weren't getting used for distribution.
Fixes example in Type.asSeenFrom
Fix for SI-6600, regression with ScalaNumber.
SI-6562 Fix crash with class nested in @inline method
Brings copyrights in Scaladoc footer and manpage up-to-date, from 2011/12 to 2013
Brings all copyrights (in comments) up-to-date, from 2011/12 to 2013
SI-6606 Drops new icons in, replaces abstract types placeholder icons
SI-6132 Revisited, cleaned-up, links fixed, spelling errors fixed, rewordings
Labeling scala.reflect and scala.reflect.macros experimental in the API docs
Typo-fix in scala.concurrent.Future, thanks to @pavelpavlov
Remove implementation details from Position (they are still under reflection.internal). It probably needs more cleanup of the api wrt to ranges etc but let's leave it for later
SI-6399 Adds API docs for Any and AnyVal
Removing actors-migration from main repository so it can live on elsewhere.
Fix for SI-6597, implicit case class crasher.
SI-6578 Harden against synthetics being added more than once.
SI-6556 no assert for surprising ctor result type
Removing actors-migration from main repository so it can live on elsewhere.
Fixes SI-6500 by making erasure more regular.
Modification to SI-6534 patch.
Fixes SI-6559 - StringContext not using passed in escape function.
...
Conflicts:
src/actors-migration/scala/actors/migration/StashingActor.scala
src/compiler/scala/tools/nsc/backend/jvm/GenASM.scala
src/compiler/scala/tools/nsc/settings/AestheticSettings.scala
src/compiler/scala/tools/nsc/transform/Erasure.scala
src/library/scala/Application.scala
src/library/scala/collection/immutable/GenIterable.scala.disabled
src/library/scala/collection/immutable/GenMap.scala.disabled
src/library/scala/collection/immutable/GenSeq.scala.disabled
src/library/scala/collection/immutable/GenSet.scala.disabled
src/library/scala/collection/immutable/GenTraversable.scala.disabled
src/library/scala/collection/mutable/GenIterable.scala.disabled
src/library/scala/collection/mutable/GenMap.scala.disabled
src/library/scala/collection/mutable/GenSeq.scala.disabled
src/library/scala/collection/mutable/GenSet.scala.disabled
src/library/scala/collection/mutable/GenTraversable.scala.disabled
src/library/scala/collection/parallel/immutable/ParNumericRange.scala.disabled
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Have to keep a sharp eye on those ReusableCBFs.
Now all the indexed sequences should be using the
same instance.
|
| | |
| |
| |
| | |
I also realized it didn't have to be lazy, and made it so.
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
Removes the `VectorReusableCBF` and pattern matching on it in optimized `Vector` methods.
Instead, we now have a new `ReusableCBF` instance in `IndexedSeq` and check for equality
when trying to optimize `:+`, `+:` and `updated`.
This overridden `ReusableCBF` is used by `IndexedSeq`, `immutable.IndexedSeq` and
`immutable.Vector`.
The net effect is that calling `:+` and similar methods on a `Vector` instance with
a `CBF` that came from `IndexedSeq` or somewhere lower in the hierarchy will always
create a `Vector` using the optimized method.
|
| |
|
|
|
|
|
|
|
|
| |
- 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.
|
| |
|
|
| |
inference
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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].
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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?
|
| |
|
|
|
|
| |
Added an override to immutable.IndexedSeq#toIndexedSeq which returns
itself. Closes #3732, no review.
|
| |
|
|
|
| |
Removed more than 3400 svn '$Id' keywords and related junk.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
removed some of the code duplication that Martin pointed out in my addition of def apply() to GenericCanBuildFrom
|
| |
|
