This question already has answers here:
Scala equivalent of Java java.lang.Class<T> Object
(2 answers)
Closed 3 years ago.
Suppose you have a Scala case class like this:
case class A(a: Int, b: Int)
How to get the Class representation of it, the one you usually get with .getClass?
What does NOT work:
Calling A.getClass will not give you the class information, but rather the accompanying auto-generated object. You can observe it by calling: A.getClass.getDeclaredFields.toList, which will give you this list: List(public static A$ A$.MODULE$) instead of a and b fields.
Calling A(null, null).getClass does work because we instantiate a dummy object, but it's more verbose, feels dirty, and comes at odds with compiler linters like "wartremover".
Use Scala-s built-in classOf[A]. The correct type will then be automatically inserted by the Scala compiler.
Related
This question already has answers here:
Difference between case object and object
(7 answers)
Closed 6 years ago.
I read and understand, case class is to send arguments and create multiple object and case object don't send any arguments and having single object. So that will achieve by object also why case object.
Why is case object important and when? I already gone through this post, but I did not get why case object.
Difference between case class and case object?
Well... an object in Scala can be "roughly" explained as an instance of an anonymous class. Now the difference in a case object and object lies in the difference of that anonymous class being a case class or just a class
To put it more clearly,
object A
// is roughly equivalent to something like
class AnonymousClass12345
val A = new AnonymousClass12345()
Where as for case object,
case object A
// is roughly equivalent to something like,
case class AnonymousClass12345
val A = new AnonymousClass12345()
And now it should be very easy to relate to case class vs class. And as an instance of an anonymous case class, case object gets all the goodies that any instance of any other case class does.
Note :: This answer is meant to provide an inaccurate but easy to understand explanation. A more accurate answer of this question will require not only an understanding of the difference class vs type which is nicely (but not very accurately) discussed in this - answer but also of Scala reflection.
This question already has answers here:
Get companion object of class by given generic type Scala
(5 answers)
Closed 6 years ago.
Is it possible in Scala to get the singleton instance of an object when I only have the class? Consider
object A {}
def getSingletonInstance[T](x: Class[T]): Option[T] = {
// output the singleton, if x is a singleton class i.e. defined by an object
// is this possible?
}
getSingletonInstance(A.getClass) // --> should return Some[A]
There are many questions on SO discussing different ways of doing this.
One of them I referenced in a comment to your question.
Here is another one, using "official" scala reflection: Get companion object instance with new Scala reflection API
If you don't mind an approach, involving a little "hacking" (as in using some unofficial/undocumented/coincident features rather than an official API), you can do it much easier with something like this:
val clazz = Class.forName(x.getName + "$")
val singleton = clazz.getField("MODULE$").get(clazz)
Note that a companion object of class T does not have to be an instance of T, so the declaration of your getSingletonInstance won't always work.
EDIT I did not realize that you were passing the class of the object itself to your function, not the companion class. In that case, you don't need to append it with dollar sign in the above code, and don't even need the first line at all. You can just do x.getField("MODULE$").get(x)
This question already has answers here:
Explicit self-references with no type / difference with ''this''
(2 answers)
Closed 6 years ago.
When I look at the code of scala.collection.TraversableLike I see that it starts with self =>
What does it mean?
This is usually used as an alias to "this" variable. Why do you even need this? Consider a simple example:
class A{
self=>
def generate = 5
class B{
def generate:Int = {
self.generate+5
}
}
def o = (new B).generate
}
val a = new A
a.o
If you change "self" to "this" you will get StackOverflowException. Why? Because "this.generate" inside the nested class refers to the method "generate" of class B. So in order to get access to the method "generate" of class A we created an alias to "this".
You could have also wrote:
A.this.generate
instead. And it works too.
You might me also interested in this article.
http://www.markthomas.info/blog/92
It's something called self-type annotation and allows two things:
aliasing this (helpful in nested classes or traits, where this would give you the access to the inner class, and self would give you the access to the outer class),
specifying
additional requirements about this (it works very similar to
inheritance then, you can see examples and differences here)
This question already has answers here:
What is the rationale behind having companion objects in Scala?
(7 answers)
Closed 7 years ago.
As we know we don't have static methods in scala. If we have to achieve that taste we declare that class as object. But the problem is that when we declare class as object then all methods present in that object becomes static. And in class all methods all non-static. What I want is that to have static as well as non static methods in the same class, Is it possible? Definitely it would be possible but how??????
To do what you are trying do in Scala you create an object and a class of same name. Put static in object and instance members in Class version of it. This object is called a companion object.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
“new” keyword in Scala
Ive noticed that creating certain instances in Scala you can leave off using new. When is it required that a developer use new? And why do some objects allow you to miss off using it?
Thanks
List("this","is","a","list") creates a List of those four strings; no
new required
Map("foo" -> 45, "bar" ->76) creates a Map of String to Int, no new
required and no clumsy helper class.
Taken from here..
In general the scala collection classes define factory methods in their companion object using the apply method. The List("this","is","a","list") and Map("foo" -> 45, "bar" ->76) are syntactic sugar for calling those apply methods. Using this convention is fairly idiomatic scala.
In addition if you define a case class C(i: Int) it also defines a factory C.apply(i: Int) method which can be called as C(i). So no new needed.
Other than that, the new is required to create objects.