What's the benefit of Scala (singleton) object vs. typical class level artifacts

Question

I understand one of the main benefits from using object is, they are real objects instead of system wide functionality. But finally those objects are also system wide accessible.

Beside of being more "pure" what additional benefit does scala "objects" offer.

I bet there are a number but I can't really figure out which.

See also http://stackoverflow.com/questions/4112088/why-are-singleton-objects-more-object-orientated — Aaron Novstrup, Dec 20 '10 at 20:49
See also http://stackoverflow.com/questions/609744/what-is-the-rationale-behind-having-companion-objects-in-scala — Craig P. Motlin, Dec 20 '10 at 22:38

score 14 · Accepted Answer · answered Dec 20 '10 at 18:43

14

objects are independent entities, e.g. they can be used as method arguments, as target for implicit conversions, and case objects in pattern matching...
objects can inherit from classes or traits
an object has its own type
objects can restrict the access of its members, even for the companion class:

.

object X {
  private[this] val z=1 
}

class X { 
  import X._ 
  //won't compile 
  println(z)
}

answered Dec 20 '10 at 18:43

Landei

54,104
13
100
195

+1 It's a shame you have to use a different access modifier ( or a special version at least ) Can you post a sample of passing the object as argument? Also, why can't object inherit from other objects? ( I mean, I know technically why, I wonder if there is a design reason also ) – OscarRyz Dec 20 '10 at 19:08
7

"Can you post a sample of passing the object as argument?" I guess you did this already yourself without noting it. For example you can pass Nil when a List is required (or None, when you need an Option), and Nil is an object. Concerning why objects can't inherit from objects, I think it's not a technical but more a "philosophical" question: Is a singleton a singleton if it can have children? I'd rather say, no, it's not. – Landei Dec 20 '10 at 19:16
3

@OscarRyz: Which access modifier would you want to use instead? It’s Scala’s normal ‘instance private’ modifier after all. (Some might not know but using `private[this]` in a class makes a variable invisible for other instances as well, whereas with `private` it could still be accessed by sister instances.) – Debilski Dec 22 '10 at 00:32

nanda · Answer 2 · 2010-12-20T19:09:53.190

2

One advantage I can see is that the object will always be lazily initialized. Static on Java will be initialized when a class is accessed even if the static itself is not used.

See this Java code:

class StaticJava {

  static String AA = "Static String";

  StaticJava() {
  }

}

When I call StaticJava constructor, AA will always initialized, even if it is not used.

On Scala:

object StaticScala {
  val AA = "Static String"
}

class StaticScala

Since the object StaticScala will be translated to something like StaticScala$, calling the constructor of StaticScala class will not initialize the singleton object.

edited Dec 20 '10 at 19:09

answered Dec 20 '10 at 18:29

nanda

24,458
13
71
90

Um, I don't see that as really any different to Java. – Tom Hawtin - tackline Dec 20 '10 at 18:33
The Java version is missing a `final` modifier on `AA` (or maybe you meant `var` rather than a `val` in the Scala version). – Aaron Novstrup Dec 20 '10 at 20:53
I'm still not seeing it as really any different to Java. Put the Java version in two classes (the equivalent of the Scala version) and you get the same thing. – Tom Hawtin - tackline Dec 20 '10 at 22:30

score 2 · Answer 3 · answered Dec 20 '10 at 18:55

2

The use of singleton objects as a replacement for static containers have as much advantage as OO has over purely imperative programming. After all, static stuff is essentially imperative, and singleton objects are object oriented.

answered Dec 20 '10 at 18:55

Daniel C. Sobral

295,120
86
501
681

1

Which brings my question back: *Beside of being more "pure" what additional benefit do scala objects offer.* – OscarRyz Dec 20 '10 at 18:58
@OscarRyz There are other documents describing the benefits of object orientation. – Daniel C. Sobral Dec 20 '10 at 22:15
1

Singletons are just static stuff in a bad disguise. – Tom Hawtin - tackline Dec 20 '10 at 22:27
@Tom Care to explain how the advantages of singleton objects in Landei's answer and in Kevin's answer to a related question (http://stackoverflow.com/questions/4112088/why-are-singleton-objects-more-object-orientated) are "a bad disguise"? – Aaron Novstrup Dec 20 '10 at 22:53
@Tom No, Tom, you are wrong. Singletons are full objects like any other: they belong to a class, may have interfaces, may have a constructor, one can pass it around like any other object, call methods on it, use reflection, check for class type and cast them. There are three things that set them apart from other objects: their initalization is delayed until needed, they share private scope access with their companion classes, if they happen to have one, and the class they directly belong to is guaranteed to have only them as member (a bit like they were anonymous subclassed). – Daniel C. Sobral Dec 20 '10 at 23:35
@Tom Therefore, they are neither disguised -- since they are real objects -- nor are they simply "static stuff". Rather, they _precude the need for static stuff_ by offering an object oriented alternative. Of course, Scala classes contain static forwarders to companion objects so that Java can call them. – Daniel C. Sobral Dec 20 '10 at 23:37

score 1 · Answer 4 · answered Dec 20 '10 at 19:03

The real question should be: why using singletons instead of static classes (static method and fields).

For sure one benefit is that removing static simplify compiler and runtime method resolution.

Another benefit is that having singletons supported by the language is very useful when you write you're own code, you don't have to use dirty trick like private constructors and the orrible getInstance() static method. So much cleaner syntax.

Finally static methods and fields are a nightmare for concurrency unwanted sideeffects.

Tom Hawtin - tackline · Answer 5 · 2010-12-20T18:36:19.853

-2

As far as I can tell the advantage is economy of syntax. Now you don't need any static invocation and field referencing nonsense. They are also cleaner than a single element enum for implementing a strategy (that is, a stateless class implementing an interface).

You might argue that they separate out the static parts too.

The other side of that is that mutable statics are already too easy in Java. Scala hides and legitimatises them.

edited Dec 20 '10 at 18:36

answered Dec 20 '10 at 18:30

Tom Hawtin - tackline

145,806
30
211
305

(I should say that I've never written a line of Scala.) – Tom Hawtin - tackline Dec 20 '10 at 18:36
Scala neither hides nor legitimizes mutable statics. If you want a mutable reference, you use a `var`. If you want an immutable reference, you use a `val`. The use of `var`s is discouraged in idiomatic Scala in general, but especially in a public member of an object. – Aaron Novstrup Dec 20 '10 at 20:57
@Aaron Novstrup As far as I know `var` vs `val` has nothing to do with statics. – Tom Hawtin - tackline Dec 20 '10 at 22:24
Maybe I'm misunderstanding what you meant by _mutable statics_ -- I assumed you meant mutable static members. If not, in what sense are Scala's `object` s ever mutable? – Aaron Novstrup Dec 20 '10 at 22:33

What's the benefit of Scala (singleton) object vs. typical class level artifacts

5 Answers5