What is the equivalent of java.util.Collection? I first thought Seq is the way to go, but actually it's an ordered set of elements. I mean we have a numeration of elements.
Collection Hierarcy
Traversable is on top above iterable
The picture above is very good looking, but it is not helpful at all in answering the question. (It may be helpful as general reference for other purposes, but not for this purpose.) It is even missing some very important interfaces. So, here is some good old text to try and clear out the confusion:
The Scala equivalent to java.util.Collection is scala.collection.Iterable, despite the mismatch in the name.
You see, scala.collection.Iterable offers the basic functionality of a Java Collection: it has an iterator and a size.
Apparently, what Java calls Iterable Scala calls it Traversable, and then what Java calls Collection Scala calls it Iterable.
Related
I am new to Scala and trying to explore how I can use Java functionalities with Scala.
I am having stream of LocalDate which is a Java class and I am trying to find maximum date out of my list.
var processedResult : Stream[LocalDate] =List(javaList)
.toStream
.map { s => {
//some processing
LocalDate.parse(str, formatter)
}
}
I know we can do easily by using .compare() and .compareTo() in Java but I am not sure how do I use the same thing over here.
Also, I have no idea how Ordering works in Scala when it comes to sorting.
Can anyone suggest how can get this done?
First of all, a lot of minor details that I will point out since it seems you are pretty new to the language and I expect those to help you with your learning path.
First, avoid var at all costs, especially when learning.
While mutability has its place and is not always wrong, forcing you to avoid it while learning will help you. Particularly, avoid it when it doesn't provide any value; like in this case.
Second, this List(javaList) doesn't do what you think it does. It creates a single element Scala List whose unique element is a Java List. What you probably want is to transform that Java List into a Scala one, for that you can use the CollectionConverters.
import scala.jdk.CollectionConverters._ // This works if you are in 2.13
// if you are in 2.12 or lower use: import scala.collection.JavaConverters._
val scalaList = javaList.asScala.toList
Third, not sure why you want to use a Scala Stream, a Stream is for infinite or very large collections where you want all the transformations to be made lazily and only produce elements as they are consumed (also, btw, it was deprecated in 2.13 in favour of LazyList).
Maybe, you are confused because in Java you need a "Stream" to apply functional operations like map? If so, note that in Scala all collections provide the same rich API.
Fourth, Ordering is a Typeclass which is a functional pattern for Polymorphism. On its own, this is a very broad question so I won't answer it here, but I hope the two links provide insight.
The TL;DR; is simple, it is just that an Ordering for a type T knows how to order (sort) elements of type T. Thus operations like max will work for any collection of any type if, and only if, the compiler can prove the existence of an Ordering for that type if it can then it will pass such value implicitly to the method call for you; again the implicits topic is very broad and deserves its own question.
Now for your particular question, you can just call max or maxOption in the List or Stream and that is all.
Note that max will throw if the List is empty, whereas maxOption returns an Option which will be empty (None) for an empty input; idiomatic Scala favour the latter over the former.
If you really want to use compareTo then you can provide your own Ordering.
scalaList.maxOption(Ordering.fromLessThan[LocalDate]((d1, d2) => d1.compareTo(d2) < 0))
Ordering[A] is a type class which defines how to compare 2 elements of type A. So to compare LocalDates you need Ordering[LocalDate] instance.
LocalDate extends Comparable in Java and Scala conveniently provides instances for Comparables so when you invoke:
Ordering[java.time.LocalDate]
in REPL you'll see that Scala is able to provide you the instance without you needing to do anything (you could take a look at the list of methods provided by this typeclass).
Since you have and Ordering in implicit scope which types matches the Stream's type (e.g. Stream[LocalDate] needs Ordering[LocalDate]) you can call .max method... and that's it.
val processedResult : Stream[LocalDate] = ...
val newestDate: LocalDate = processedResult.max
I'm currently porting some code from traditional Scala to Scalaz style.
It's fairly common through most of my code to use the Seq trait in my exposed API signatures rather than a concrete type (i.e. List, Vector) directly. However, this poses some problem with Scalaz, since it doesn't provide an implementation of a Bind[Seq] typeclass.
i.e. This will work correctly.
List(1,2,3,4) >>= bindOperation
But this will not
Seq(1,2,3,4) >>= bindOperation
failing with the error could not find implicit value for parameter F0: scalaz.Bind[Seq]
I assume this is an intentional design decision in Scalaz - however am unsure about intended/best practice on how to precede.
Should I instead write my code directly to List/Vector as appropriate instead of using the more flexible Seq interface? Or should I simply define my own Bind[Seq] typeclass?
The collections library does backflips to accommodate subtyping: when you use map on a specific collection type (list, map, etc.), you'll (usually) get the same type back. It manages this through the use of an extremely complex inheritance hierarchy together with type classes like CanBuildFrom. It gets the job done (at least arguably), but the complexity doesn't feel very principled. It's a mess. Lots of people hate it.
The complexity is generally pretty easy to avoid as a library user, but for a library designer it's a nightmare. If I provide a monad instance for Seq, that means all of my users' types get bumped up the hierarchy to Seq every type they use a monadic operation.
Scalaz folks tend not to like subtyping very much, anyway, so for the most part Scalaz stays around the leaves of the hierarchy—List, Vector, etc. You can see some discussion of this decision on the mailing list, for example.
When I first started using Scalaz I wrote a lot of utility code that tried to provide instances for Seq, etc. and make them usable with CanBuildFrom. Then I stopped, and now I tend to follow Scalaz in only ever using List, Vector, Map, and Set in my own code. If you're committed to "Scalaz style", you should do that as well (or even adopt Scalaz's own IList, ISet, ==>>, etc.). You're not going to find clear agreement on best practices more generally, though, and both approaches can be made to work, so you'll just need to experiment to find which you prefer.
I have been looking around, but most of them point to a java TreeMap. The only issue with that is I do not want to convert any Scala into java and back. If there really is no way, then I am ok with that, but I would like to hear it from some professionals just to be 100% sure and to have this question on here for others in the future to stumble upon when they have a similar issue. Thanks in advance.
EDIT:
Type: scala.collection.mutable.HashMap[String, String]
In general, a Scala HashMap does not guarantee the original order.
However, there is the LinkedHashMap, which states: "The iterator and all traversal methods of this class visit elements in the order they were inserted."
What is the exact type you are dealing with? If you can decide which implementation to use, then you can choose one that maintains order. If you are just given something of type HashMap, then you're out of luck.
Scala has both a mutable and an immutable Map ,
but it has only an immutable List.
If you want a mutable List you need a ListBuffer.
I don't understand why this is so.
Any one knows?.
You can choose between these:
scala.collection.mutable.DoubleLinkedList
scala.collection.mutable.LinkedList
scala.collection.mutable.ListBuffer
scala.collection.mutable.MutableList
So, yes, Scala has mutable lists :-)
I hope that this article may be of some use to you. The diagram at the bottom of the page is particularly useful in providing the mutable and immutable classes.
http://www.scala-lang.org/docu/files/collections-api/collections_1.html
There is a mutable List, but it is called Buffer. The article linked by Graham goes into more depth, but I thought there should be a specific answer to the question as well.
Map is a trait -- like Java's interface --, while List is a class, a concrete implementation of a Seq. There are mutable and immutable Seq, just like for Map.
This may be confusing to Java programmers because, in Java, List is an interface, whose (main) implementations are ArrayList and LinkedList. Alas, Java naming is atrocious. First, ArrayList is not a List by any stretch of imagination. Also, the interface has methods that are not really related to any traditional list.
So, if you want mutable/immutable equivalence, look to concrete subclass implementations of Seq.
Is there a reason that the object TreeSet.apply method returns SortedSet and not TreeSet?
The following code won't compile in scala 2.7
val t:TreeSet[Int] = TreeSet(1,2,3)
The literal answer is because apply() is implemented in terms of ++, which is defined in SortedSet, and hence returns a SortedSet. ++ then goes on to use +, which is defined in TreeSet, so you can cast it back to TreeSet if it's critical (though I wouldn't recommend it, as it is implementation dependent and may change over time!).
What do you need from TreeSet that you can't get from SortedSet?
I'm not sure what the rationale behind the design decision is, though it looks like it has changed in 2.8.
This has been identified as a short coming of the current scala collection library, and is addressed in the revamped collection library that is part of scala 2.8. See http://www.scala-lang.org/sid/3# for the gory details.