Why does Scala contain static elements inside a class?

Question

I know you can identify them indirectly to achieve something similar with related objects, but I wonder why, as a language design, statistics from class definitions were disabled.

Answer 1

I also posted this question in the scala google group and Bill Venners user groups, one of the authors of the answer "Programming in scala" had some ideas.

Take a look at this: https://groups.google.com/d/msg/scala-user/5jZZrJADbsc/6vZJgi42TIMJ and https://groups.google.com/d/msg/scala-user/5jZZrJADbsc/oTrLFtwGjpEJ

Here is an excerpt:

I think that one goal was simply to be simpler, having each value as an object, each operation calls a method call. The static and Java primitives are special cases, which makes the language more “complex” in some sense.

But the other big one, I think, should have something that can match Java statics in scala (because scala needs some kind of construct that maps to Java statics for interaction), but this is beneficial for OO inheritance / polymorphism. Singleton objects are real objects. They can expand the superclass or mix in features and go as such, but they are also “static” in nature. This proves to be very convenient in practice.

Also take a look at this interview with Martin Odersky (scroll down to object-oriented innovations in the scala section) http://www.artima.com/scalazine/articles/goals_of_scala.html

Here is an excerpt:

At first, we wanted to be a pure object-oriented language, where each value is an object, each operation is a method call, and each variable is a member of an object. Therefore, we do not need static, but we need to replace something, so we created the construction of singleton objects. But even singleton objects are still global structures. Therefore, the task was to use them as little as possible, because when you have a global structure, you can no longer change it. You cannot create an instance. This is very difficult to verify. It is very difficult to change it in any way.

Summarizing:

From the point of view of functional programming, static members are usually considered bad (see this post by Gilad Bracha - the father of generic java. To do with side effects due to the global state). But scala had to find a way to interact with Java (therefore, it had to maintain statics) and minimize (although not completely avoid) global states created due to statics, scala decided to isolate them in companion objects.

Companion objects can also be extensible, i.e. use the composition of inheritance and mixing (separately from emulating static functionality for interaction).

Answer 2

O in OO means "object", not a class. Object Oriented is all objects or instances (if you prefer)

Statics do not belong to the object, they cannot be inherited, they do not participate in polymorphism. Simply put, statics are not object oriented.

Scala, on the other hand, is object oriented. This is much more than Java, which especially tried to behave like C ++ in order to attract developers from this language.

This is a hack invented by C ++, which sought to overcome the worlds of procedural and OO programming and had to be backward compatible with C. It also recognized primitives for the same reasons.

Scala rolls statics and primitives because they are a relic of a time when ex-procedural developers needed to be reassured. These things do not occur in any well-designed language that wants to describe itself as object-oriented.

---

Regarding why this is important for truly OO, I'm going to shamelessly copy and paste this excerpt from Bill Venners on the mailing list:

The way I look at this is that singleton objects allow you to do static things where they are needed in a very concise way, but also benefit from inheritance when you need to. One example is to simply check the static parts of your program, because you can make traits that simulate these parts and use traits everywhere. Then, in the production program, single-element implementations of objects of these traits are used, but mock-ups are used in tests.

Couldn't have said better myself!

So, if you want to create just something, then both static and single games can do the job. But if you want one thing to inherit behavior somewhere, then statics won't help you.

In my experience, you tend to use this ability much more than you initially thought, especially after you have used Scala for a while.

Answer 3

This is what appears in my head when I think about how statics can complicate things:

1) Inheritance, as well as polymorphism, will require special rules. Here is an example:

// This is Java public class A { public static int f() { return 10; } } public class B extends A { public static int f() { return 5; } } public class Main { public static void main(String[] args) { A a = new A(); System.out.println(af()); B b = new B(); System.out.println(bf()); A ba = new B(); System.out.println(ba.f()); } } 

If you are 100% sure that it is printed, good for you. The rest of us can reliably rely on powerful tools, such as the @Override annotation, which, of course, is optional and the friendly "Static method f () of type A must be available in a static way" warning. It brings us to

2) The "static path" of access to the material is an additional special rule that complicates the situation.

3) Static members cannot be abstract. You probably can't have everything, right?

And again, this is all that occurred to me after I thought about this a few minutes. I bet there are many other reasons why statics just don't fit into the OO paradigm.

Answer 4

Verily, a static member does not exist, BUT, it is possible to associate a singleton object with each class:

 class MyClass { } object MyClass { } 

for similar results

Answer 5

Object-oriented programming is all objects and its states (without touching the state of a complete and stateless object). Im trying to emphasize "Static does not belong to objects". Static fields cannot be used to represent the state of an object ; therefore, it is rational to separate it from objects.