I know you can define them indirectly through companion objects but I am wondering why as a language design were statics dropped out of class definitions.
I posted this question on Stackoverflow but didn't really get a deep answer. I am hoping language enthusiasts can provide a clear explanation.
To give an example:
scala> trait A { def b: Int }
defined trait A
scala> object B extends A { override def b = 5 }
defined module B
scala> def m(a: A) = a.b
m: (a: A)Int
scala> m(B)
res0: Int = 5
Best,
Ismael
Nobody said that statics are bad. They said they belong to a "static
object", ie. something that can't be photocopied over the JVM, that is
unique in a JVM instance. Ie., objects.
I find it is a neat separation of concerns, putting all stuff you can
override or that need to exist in each instance in classes, and static
stuff in objects.
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
You may get some insight from this interview with Martin Odersky:
http://www.artima.com/scalazine/articles/goals_of_scala.html
Scroll down to the "Object-oriented innovations in Scala". I think one
goal was simply to be simpler, by having every value be an object,
every operation a method call. Java's statics and primitives are
special cases, which makes the language more "complicated" in some
sense.
But another big one I think is to have something you can map Java's
statics to in Scala (because Scala needed some construct that mapped
to Java's statics for interop), but that benefits from OO
inheritance/polymorphism. Singleton objects are real objects. They can
extend a superclass or mix in traits and be passed around as such, yet
they are also "static" in nature. That turns out to be very handy in
practice.
Bill
--
Bill Venners
Artima, Inc.
http://www.artima.com
I'm not sure he wanted to shun them altogether, but either way he did
have to come up with some way to deal with them given the VMs Scala
was supposed to run on in interact with. The way I look at it, though,
is that singleton objects allow you to do the static things where they
are needed in a very concise way, but also benefit from inheritance
when you need to. One example is it is easier to test the static parts
of your program, because you can make traits that model those parts
and use the traits everywhere. Then in the production program use a
singleton object implementations of those traits, but in tests use
mock instances.
Bill
----
Take the problem from the other side: how, putting statics in classes, it can help with
inheritance or polymorphism?
If you cannot use them this way, you can as well put them out of the way, in a separate
instance.
Not to offend, but you have already received several good answers. Your response has typically been, "Yes, but I can do that in Java by..." or "I don't need to do that because...". However, Scala objects let you do static-type things _more cleanly_ than you can in Java, and the additional abilities of objects are put to good use in many places _even if_ you don't use them. Plus, my understanding is that objects over statics allowed some simplification of the compiler design.Ken