I'm very confused by Scala's HashSet and Set types as they both seem to do the same thing.
What is the difference between them?
Is it the same in Java?
In my reference it says that HashSet is an "explicit set class" (as compared to Set). What does that mean?
Scala's mutable and immutable HashSet implementations are concrete classes which you can instantiate. For example, if you explicitly ask for a new scala.collection.immutable.HashSet, you will always get a set which is implemented by a hash trie. There are other set implementations, such as ListSet, which uses a list.
Set is a trait which all the set implementations extend (whereas in Java, Set is an interface).
Set is also a companion object* with an apply** method. When you call Set(...), you're calling this factory method and getting a return value which is some kind of Set. It might be a HashSet, but could be some other implementation. According to 2, the default implementation for an immutable set has special representation for empty set and sets size up to 4. Immutable sets size 5 and above and mutable sets all use hashSet.
*In Scala, instead of having static class methods, you can create a singleton object with the same name as your class or trait. This is called a companion object, and methods you define on it can be called as ObjectName.method(), similar to how you'd call a static method in Java.
**Set(x) is syntactic sugar for Set.apply(x).
Related
I have read how companion and singleton objects can be used to keep static methods, which makes sense. My question is how is this object made or instantiated it? I have read from some sources on how Objects are instances of the class if used as companion objects while others say they are not instances of the class. Then how are the objects existing or being made? Plus the Object would be same class data type I suppose?
My question is how is this object made or instantiated it?
[…]
Then how are the objects existing or being made?
You don't know, shouldn't know, and can't know.
The Scala Language Specification says that they exist. The Scala Language Specification does not say how they are instantiated. Every implementor is free to implement them however they want.
For example, ECMAScript has object literals, so for Scala.js, there is no need for them to be an instance of any class at all. Scala-native is not dependent on any platform, so it can do whatever it wants. Scala-JVM needs to comply with the restrictions of the JVM, where every object needs to be an instance of a class. In Scala-JVM, every singleton object Foo is an instance of a JVM class named Foo$.
Plus the Object would be same class data type I suppose?
The type of a singleton object Foo is the singleton type Foo.type. It's not a class.
I have read from some sources on how Objects are instances of the class if used as companion objects while others say they are not instances of the class.
Instead of reading "some sources", it's much better to just read the source: the Scala Language Specification, specifically section 5.3.2 Case Classes:
A case class definition of 𝑐[tps](ps1)…(ps𝑛) with type parameters tps and value parameters ps implies the definition of a companion object, which serves as an extractor object. It has the following shape:
object 𝑐 {
def apply[tps](ps1)…(ps𝑛): 𝑐[tps] = new 𝑐[Ts](xs1)…(xs𝑛)
def unapply[tps](𝑥: 𝑐[tps]) =
if (x eq null) scala.None
else scala.Some(𝑥.xs11,…,𝑥.xs1𝑘)
}
Each object has its own class, but you can't access the class directly. This class has a constructor without parameters which is called automatically when it's loaded and creates the only instance.
Objects are instances of the class if used as companion objects
Either you misunderstood or you really shouldn't trust these sources. It's possible for a companion object to extend the trait/class it's companion to, but not at all common.
Companion objects are not instances of the class they're companion of, think of them more like a collection of utility methods. If you're familiar with Java - all the method, that you made static in Java (hence they don't belong to a particular instance, but to class in general) would go to Companion object in Scala. Also, companion objects have access to classes private values.
Objects are lazily initialized for you, you don't need to know when and how exactly are they created, just if you call a function from an object - it will be created for you, and there will be only one instance of it.
I know that Scala List can be created as :
val l = List(1,2,3)
What goes on under the hood when the above statement is executed ?
Is the apply method called here ?
Per the scala documentation : For sequences, apply is positional indexing
http://docs.scala-lang.org/overviews/collections/seqs.html
So , are there 2 apply methods , one for positional indexing & another as the factory method for object creation ?
This invocation actually calls the apply method on the companion object to the List class.
Many scala classes have a companion object, which is a singleton object with the same name as the class. Defining methods on this companion object, is the scala equivalent of java's static methods. It is very common for these companion objects to have one or more apply methods that are used as constructor/factory functions to create an instance of the class. In this case the List object has a method that takes a variable number of arguments of the same type, and creates a List of those objects.
In fact, if you define a case class, scala will automatically define a companion object that, among other things, includes and apply method that takes the same arguments as the case class's constructor, which is why you don't need to use new when constructing case classes.
The list instance also has an apply method, which is used to index into the list, but since it is defined on the List class it only applies to instances of the class, not the object List itself.
Coming from the Java world, I don't see how the restrictions on the auxiliary constructors in Scala are helpful ..
In Java, I know we can have multiple constructors as long as their signatures are different.
In Scala, the first call in an auxiliary constructor needs to be another auxiliary constructor or the class's primary constructor. Why? Doesn't this make Scala more restrictive?
Scala essentially guarantees that the primary constructor will always be called, so it gives a single point of entry to the class; FOREVER. You ALWAYS know that the primary constructor will be called, no matter which auxiliary constructor you use to create the object.
Did you even experience having all your nice initialization in your (say) argument-less constructor in Java, and then you (in the future) or someone else coming along creating another constructor and then your objects are not correctly initialized and start miss-behaving? Probably not the best design in the world, but I faced this, and it wasn't fun.
Well, in Scala you never have to worry about this, if you have something in your primary constructor it will always be called or else the code will not compile. In my vocabulary it's not a restriction, it's called "Peace of Mind".
Scala doesn't support multiple constructors like Java. While this may seem like an inconvenience, in return you get less boilerplate. And with factory methods in the companion object you end up getting a richer syntax for construction.
Scala needs to have a primary constructor because you can include declarations in it and eliminate the tedious boilerplate of initializing a field in the constructor.
class Rectangle(val width: Int, val height: Int) {
def this(size: Int) = this(size, size)
}
Note that the 'val' keywords in the default constructor declare two public fields. The idiomatic Java equivalent would have a lot more boilerplate (two getters, plus initialization in the constructor).
Actually in practice most developers prefer factory methods in the companion object (e.g. Rectangle(4) instead of new Rectangle(4, 4)), which is more flexible overall.
Is the answer to this :
Instantiation of the object uses 'val' instead of 'var'.
Each member variable of the object being created is also 'val' instead of 'var'. This is to prevent users updating an object value after its set.
An object is immutable if there is no way for the user of that object to mutate it. This means that it must have no public methods that reassign any of its member variables or mutate any objects referred to by those variables. If all the object's members are vals this ensures the former (i.e. they can't be reassigned), but not the latter (i.e. if the objects referred to by those variables are themselves mutable, they can still be mutated by calling mutating methods on them even if they're referred to only by vals).
Also note that even if the members are declared as vars, the object can still be immutable if none of the object's methods actually reassign the variables (or call mutating methods on them) - assuming of course, they're private.
So having only val members is neither necessary nor sufficient for an object being immutable. Whether the object is referred to by a val or a var (or both) makes no difference in that matter.
#sepp2k nicely and correctly explains the criteria for an object being technically immutable. One subtle point missing from his answer is that not all member variables correspond to externally visible state. A member may also be e.g. a cached internal value to store some local, hard to compute data which is not directly visible from outside (thus qualified as private[this] in Scala). An object can have such a var member e.g. to store a computed hash value. It can even be accessible via a public getter - as long as the behaviour of the accessor is purely functional, i.e. it always produces the same value for each invocation on the same object (except that it returns faster when reusing the internally cached value).
The Scala compiler is aware of this distinction so it can help one to implement an immutable class correctly, even when using mutable state internally. This is important when generic type variance comes into play. Namely, the compiler allows a generic type parameter to be covariant even if the class contains reassignable fields of this type - as long as these fields are private[this], ensuring that one cannot have a reference to a containing object that has a statically weaker type than the type the object was defined with (which would be a precondition for variance to cause type errors).
This is explained in more detail, with a code example, in section 19.7 of Programming in Scala.
Is it possible to create an AOP like interceptor using Scalas new Dynamic Type feature? For example: Would it be possible to create a generic stopwatch interceptor that could be mixed in with arbitrary types to profile my code? Or would I still have to use AspectJ?
I'm pretty sure Dynamic is only used when the object you're selecting on doesn't already have what you're selecting:
From the nightly scaladoc:
Instances x of this trait allow calls x.meth(args) for arbitrary method names meth and argument lists args. If a call is not natively supported by x, it is rewritten to x.invokeDynamic("meth", args)
Note that since the documentation was written, the method has been renamed applyDynamic.
No.
In order for a dynamic object to be supplied as a parameter, it'll need to have the expected type - which means inheriting from the class you want to proxy, or from the appropriate superclass / interface.
As soon as you do this, it'll have the relevant methods statically provided, so applyDynamic would never be considered.
I think your odds are bad. Scala will call applyDynamic only if there is no static match on the method call:
class Slow {
def doStuff = //slow stuff
}
var slow = new Slow with DynamicTimer
slow.doStuff
In the example above, scalac won't call applyDynamic because it statically resolved your call to doStuff. It will only fall through to applyDynamic if the method you are calling matches none of the names of methods on the type.