Why doesn't Scala have static members inside a class?

Statics don't belong to an object, they can't be inherited, they don't take part in polymorphism.  Simply put, statics aren't object-oriented.
Scala, on the other hand, *is* object oriented.  Far more so than Java, which tried particularly hard to behave like C++, in order to attract developers from that language.

They are a hack, invented by C++, which was seeking to bridge the worlds of procedural and OO programming, and which needed to be backwardly compatible with C. It also admitted primitives for similar reasons.
Scala drops statics, and primitives, because they're a relic from a time when ex-procedural developers needed to be placated.  These things have no place in any well-designed language that wishes to describe itself as object-oriented.

On 4 September 2011 23:43, Numan Salati <numan.salati@gmail.com> wrote:

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.

--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

how does defining them in object in scala help you with inheritance or polymorphism - two main problems you state with static methods.
if you could give a clear example to illustrate the point that would be great instead of "static methods are a hack".

A companion object can inherit from other classes--just like a regular class. It just can't handle generics or constructor parameters. 'Nuf said? --Bill La Forge

On Mon, Sep 5, 2011 at 6:47 AM, Numan Salati <numan.salati@gmail.com> wrote:

how does defining them in object in scala help you with inheritance or polymorphism - two main problems you state with static methods.
if you could give a clear example to illustrate the point that would be great instead of "static methods are a hack".

Personally, I think the elimination of statics with the counter-balancing addition of companion objects makes a lot of sense. It makes it very clear that the place where your "static" methods and fields live is actually a singleton object. Statics in Java always felt like you were doing two things in one place - defining the behaviour of instances, but also mashing in the behaviour of one specific instance of a completely different type of object with different methods and capabilities. 
Making inheritance in that companion object explicit and separate from that of the class/trait is also a bonus, as Bill says. Generally, defining a companion object it just feels much more consistent to me with the way the rest of the language works. Statics always felt like an awkward bolt-on in Java.
I guess a question I have here is this: what capability do you feel is missing by not having statics? What can you do with statics that you can't do with a companion object?

Iain

On Sun, Sep 4, 2011 at 9:49 PM, William la Forge <laforge49@gmail.com> wrote:

A companion object can inherit from other classes--just like a regular class. It just can't handle generics or constructor parameters. 'Nuf said? --Bill La Forge

On Mon, Sep 5, 2011 at 6:47 AM, Numan Salati <numan.salati@gmail.com> wrote:

how does defining them in object in scala help you with inheritance or polymorphism - two main problems you state with static methods.
if you could give a clear example to illustrate the point that would be great instead of "static methods are a hack".

On Mon, Sep 5, 2011 at 2:49 AM, William la Forge wrote:
> A companion object can inherit from other classes--just like a regular
> class.

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

you sound like a fanboy. please i am looking for intellectual answers not fanboyism.

> "what capability do you feel is missing by not having statics? What can you do with statics that you can't do with a companion object?"

i am trying to learn scala so just trying to understand design motivations here rather than just accept things as gospel (thats what fanboys do). 
what i would like is a clear example where statics are bad and scalas approach is superior. thats all. 
one argument i hear is "but statics aren't polymorphic". but they aren't really supposed to be so that is a moot right imo.

On 05/09/2011 06:48, Numan Salati wrote:
> what i would like is a clear example where statics are bad and scalas
> approach is superior. thats all.

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.

thanks for the example.
here are thoughts: you have just shown that you can use polymorphism with companion objects. great. 
but if i wanted polymorphic behavior i could just define an instance method. where is the clear advantage?

On 5 September 2011 06:25, Numan Salati <numan.salati@gmail.com> wrote:

thanks for the example.
here are thoughts: you have just shown that you can use polymorphism with companion objects. great. 
but if i wanted polymorphic behavior i could just define an instance method. where is the clear advantage? 

I believe you've answered your own original query.
To do this in Java, you'd have to manually create a singleton to hold those instance methods, then implement your own mechanisms to ensure that only a single instance of it existed.  Presumably with lazy initialisation semantics (read the GoF book for more info)

Scala's singleton objects come with their own (hidden) class, and already provide this behaviour, so every singleton method is also an instance method, this is in addition to being able to replace the class-wide role of statics.

--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

>To do this in Java, you'd have to manually create a singleton to hold those instance methods, then implement your own mechanisms to ensure >that only a single instance of it existed.  Presumably with lazy initialisation semantics (read the GoF book for more info)

you are missing my point. if i want polymorphic behavior in java i will create an instance method. not via singleton but happily inside my original class.
i just the argument "static methods can't be dispatched dynamically and hence take advantage of polymorphism" a moot point and slightly pedantic because i hardly ever need to do that with statics in the first place.
would love a counter example....

This is obviously going nowhere and is quickly degenerating to name-calling.
So, lets try and different tack. Perhaps a better approach is to understand your problem and work out whether (or not) the idiomatic Scala approach to solving it is superior. So, what is it that you are doing that you feel is better solved with Java statics? Give us a concrete example.
Ishaaq

On 5 September 2011 15:47, Numan Salati <numan.salati@gmail.com> wrote:

>To do this in Java, you'd have to manually create a singleton to hold those instance methods, then implement your own mechanisms to ensure >that only a single instance of it existed.  Presumably with lazy initialisation semantics (read the GoF book for more info)

you are missing my point. if i want polymorphic behavior in java i will create an instance method. not via singleton but happily inside my original class.
i just the argument "static methods can't be dispatched dynamically and hence take advantage of polymorphism" a moot point and slightly pedantic because i hardly ever need to do that with statics in the first place.
would love a counter example....

>>> one argument i hear is "but statics aren't polymorphic". but they aren't really supposed to be so that is a moot right imo.

Now who sounds like a fanboy? Java is perfect because you are already familiar with it? I understand how frustrating it can be learning Scala. It is because Scala builds on a history of important ideas that we Java programmers are unfamiliar with. So when comparing Java and Scala, remember that it is Java that is deficient, together with us old Java hacks. (I started programming in Java when Duke the Applet made his appearance.)

Bill La Forge


On Mon, Sep 5, 2011 at 10:18 AM, Numan Salati <numan.salati@gmail.com> wrote:

> "what capability do you feel is missing by not having statics? What can you do with statics that you can't do with a companion object?"

i am trying to learn scala so just trying to understand design motivations here rather than just accept things as gospel (thats what fanboys do). 
what i would like is a clear example where statics are bad and scalas approach is superior. thats all. 
one argument i hear is "but statics aren't polymorphic". but they aren't really supposed to be so that is a moot right imo.

you are making a couple of assumptions which are not correct

1. i think java is perfect. i dont
2. i find scala frustrating. i dont. actually i like lot of things about scala. and its fun learning it. 

Hi Numan,

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

On Sun, Sep 4, 2011 at 10:57 PM, Numan Salati wrote:
> you are making a couple of assumptions which are not correct
>
> i think java is perfect. i dont
> i find scala frustrating. i dont. actually i like lot of things about scala.
> and its fun learning it.

thanks bill. great article!
i never thought about it in terms of unsafe global state. what i gleaned from the article is that martin would have like to shun statics altogether (like some pure FPLs do) but for java interop companion objects were created. as a result the global structure is isolated and the original classes are safe from side effects that can happend dude to statics.
am i looking at it correctly?

Hi Numan,

On Sun, Sep 4, 2011 at 11:54 PM, Numan Salati wrote:
> thanks bill. great article!
> i never thought about it in terms of unsafe global state. what i gleaned
> from the article is that martin would have like to shun statics altogether
> (like some pure FPLs do) but for java interop companion objects were
> created. as a result the global structure is isolated and the original
> classes are safe from side effects that can happend dude to statics.
> am i looking at it correctly?
>
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
----
Bill Venners
Artima, Inc.
http://www.artima.com

Hi Numan,

Here is a hopefully helpful example. This is how we encode ADTs in Scala:  sealed trait Option[+A]case class Some[+A](value: A) extends Option[A] case object None extends Option[Nothing]
This is an example of Option ADT. Sure you can do this with statics too, but the singleton object version above is much clearer IMO.
Also, you can use singleton objects as first class modules, which is quite great.
Rahul.

On Mon, Sep 5, 2011 at 11:27 AM, Numan Salati <numan.salati@gmail.com> wrote:

you are making a couple of assumptions which are not correct

1. i think java is perfect. i dont
2. i find scala frustrating. i dont. actually i like lot of things about scala. and its fun learning it. 

On 05/09/2011 03:17, Numan Salati wrote:
> how does defining them in object in scala help you with inheritance or polymorphism - two
> main problems you state with static methods.

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.

Hi Numan,
Good question, though I would ask it in reverse: what are Java's static methods doing in an OO language? Scala is an OO language, so to have a construct allowing you to use singleton methods/classes in a way that fits in with OO concepts seems like a pretty good thing to have.
Being able to inherit form superclasses/interfaces/traits allows you to compose your singleton in a natural way out of cleanly separated sets of behaviour. Also, an 'object' may implement a contract as specified by some interface, which Java's statics can't do. 
Another advantage would be that 'objects' prevent you from littering your code with little static turds everywhere, just so you can make use of a static method somewhere down the chain. Some people apparently like to do that, and it kills your design. 
Furthermore, it becomes easy to change your mind about whether something should be a class or a singleton, so you could start your code off by creating an object out of something, and later changing it to a class so you can introduce some additional abstraction. One of the things I really love about Scala is that it allows me to type in 'pseudo' code as I'm thinking about it, and have it compile at the same time, because my pseudo code is actually valid Scala. The 'object' singletons are one of the language features facilitating this. 
Does that help?
Cheers,Erik
Op maandag 5 september 2011 00:43:27 UTC+2 schreef Numan Salati het volgende:

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.

I really like the class-companion object model in scala as compared to my experience with static vs. instance methods in Java, PHP and Python. 
In Java I just find statics to be a necessary code artifact that I can't do anything about.
In PHP and Python it's I keep wondering whether my static should just be a plain old function and vice versa
On 5 September 2011 13:12, Erik Post <eriksensei@gmail.com> wrote:

Hi Numan,
Good question, though I would ask it in reverse: what are Java's static methods doing in an OO language? Scala is an OO language, so to have a construct allowing you to use singleton methods/classes in a way that fits in with OO concepts seems like a pretty good thing to have.
Being able to inherit form superclasses/interfaces/traits allows you to compose your singleton in a natural way out of cleanly separated sets of behaviour. Also, an 'object' may implement a contract as specified by some interface, which Java's statics can't do. 
Another advantage would be that 'objects' prevent you from littering your code with little static turds everywhere, just so you can make use of a static method somewhere down the chain. Some people apparently like to do that, and it kills your design. 
Furthermore, it becomes easy to change your mind about whether something should be a class or a singleton, so you could start your code off by creating an object out of something, and later changing it to a class so you can introduce some additional abstraction. One of the things I really love about Scala is that it allows me to type in 'pseudo' code as I'm thinking about it, and have it compile at the same time, because my pseudo code is actually valid Scala. The 'object' singletons are one of the language features facilitating this. 
Does that help?
Cheers,Erik
Op maandag 5 september 2011 00:43:27 UTC+2 schreef Numan Salati het volgende:

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.

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

It also allows you to refer to and pass around references to scala objects, something you have a lot of fun trying to achieve with Java static utility classes. How many times have we all seen nasty kludges for staticutility-as-object so that things can play nicely with spring/AOP/remoting/{insert reflection-based technology here}?
Matthew

On 5 September 2011 16:59, Ken McDonald <ykkenmcd@gmail.com> wrote:

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

--
Dr Matthew PocockVisitor, School of Computing Science, Newcastle Universitymailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozertel: (0191) 2566550mob: +447535664143

Awesome point Matthew and very relevant.
On 5 September 2011 23:29, Matthew Pocock <turingatemyhamster@gmail.com> wrote:

It also allows you to refer to and pass around references to scala objects, something you have a lot of fun trying to achieve with Java static utility classes. How many times have we all seen nasty kludges for staticutility-as-object so that things can play nicely with spring/AOP/remoting/{insert reflection-based technology here}?
Matthew

On 5 September 2011 16:59, Ken McDonald <ykkenmcd@gmail.com> wrote:

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

--
Dr Matthew PocockVisitor, School of Computing Science, Newcastle University mailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozertel: (0191) 2566550mob: +447535664143

Another two of my cents: this blog article [1] made me realize how much of a no-brainer it is to have something like 'object' in your language. If you're writing Hello World, you just want an object. It's easy to explain to budding programmers; an object is a 'thing' that does something. Then, only when you need to abstract over something inside of an object, do you introduce the 'class' abstraction. 
So once again, Scala keeps things simple. For comparison's sake, try explaining:
  public class {       public static void main(...
to a beginner and you'll realize why object is a good idea. 
Cheers,Erik

[1] http://pragprog.com/magazines/2011-09/scala-for-the-intrigued

On Monday, 5 September 2011 00:43:27 UTC+2, Numan Salati wrote:

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.