Recently scala.Either was added to the source tree and then moved to
scalax because it wasn't considered mature enough.
I don't have a particularly strong opinion on this fact, but it does
highlight quite an important point: Almost none of the rest of the
standard library is mature enough either.
In fact, much of the standard library is incomplete, of questionable
value or simply broken.
I think parts of the standard library should simply be removed and
other parts should be factored out into separate projects until they
can get to a level of quality that theyr'e actually worth including as
part of the standard.
- scala.actors.*
I've not used this, but it seems popular and relatively mature (except
the remote actors!). Personally I'd feel it worked better as an
independent project, but I don't really care.
- scala.collection.*
I find scala.collection amazingly ropy. The API is poorly designed
(everything needs to override superclass methods to get the right
return type. Many classes don't), often confusing and frequently
broken. The default immutable map implementation (immutable hash map)
for example is fundamentally broken by design and doesn't even hide it
well. See e.g.
https://lampsvn.epfl.ch/trac/scala/ticket/768 . This
API is clearly crucial, but it needs serious attention.
- scala.concurrent
This is in principle useful, but is it actually used? We've got ops,
which is tentatively useful but seems to have, jolib and pilib which
are minimal, undocumented and not particularly clear as to intent.
It's a good start, but it seems to be a good start which never reached
a good middle.
- scala.dbc.*
Incomplete and abandoned as far as I can tell. Does anyone actually
use this? As far as I can tell it only supports PostgresQL and anyone
doing serious work with databases in Scala uses one of the Java ones
or have rolled their own (lift, sygneca)
- scala.io
Obviously I'm biased about the utility of scala.io.BytePickle. :-)
Anyone want to speak up for it? It isn't clear what BufferedSource is
for. it looks like a compiler internal class to me.
- scala.mobile
I assume this is there to support remote actors. Does it actually work?
- scala.ref
Fine.
- scala.reflect
Abandoned. Martin's said at various points that it never really worked
and probably shouldn't be used. But it's not marked as deprecated and
is still there.
- scala.runtime
Are these really meant to be exposed to user level code?
- scala.testing
A diversity of good testing libraries seems preferrable to having this
in the standard libraries.
- scala.text
I don't really have an opinion on this except that it looks more like
someone's toy scala project than a mature and usable part of the
standard lirbary.
- scala.util.{automata, matching, grammar, regexp}
I don't really have an opinion on these. I might do so once the
documentation project figures out what they're for and how to use
them. :-)
- scala.util.parsing.*
Given the presence of combinator and combinatorold packages, this
seems like it's variable enough that it belongs in its own separate
library.
- scala.xml.*
Seems to require language support, so presumably has to stay in the
standard library.