That’s basically what you have to do. In fact, that’s almost exactly the same thing that case class is doing for you. What you’re going to end up with is something like this:

class Foo(a: Int, b: String) {
  ...
}

object Foo {
  def apply(a: Int, b: String) = new Foo(a, b)
}

I then did some research on Lisp/Scheme Haskel, Erlang and OCAML. A few days ago I bought the pre-realease of the new Scala book and am blazing though it. The weirdnesses mentioned in the Article above make *perfect* sense from a functional language and I am *loving* the language. As for things like the p._1 – as the book explains they are for tuples which is a *core-concept* of functional languages and the syntax makes sense once you understand what they are (‘parameter 1, parameter 2) with the reason they are not array syntax being because of varying return types. I suspect the syntax is far less confusing then the ‘Anonymous Classes’ would be for those who have never seen that either.

No-one can say for certain that Scala will never replace Java on the JVM . There are two things to remember.

1) As Scala compiles to byecode then *parts* of projects can be replaced by Scala. For example, in a complex financial application, perhaps the calculation routines could be done in Scala by the senior developers and just used as a normal library by the other developers.

2) Which languages are used in the future will depend on developments in concurrency. If we start using 80 core Intel chips int he future then threading is going to ’separate the men from the boys’ as I’ve heard it described Sclala’s functional subset and it’s Actor model is going to make it start looking pretty good compared to Java.

btw, has everyone forgotten how weird Java’s constructor syntax looked compared to C++’s which we were using before Java came out?

Cheers

When you write “..Scala’s at an interesting place right now….”, I think: But will it change to the better? Isn’t it kind of rare, that a language changes in areas like the ones you mention (constructors, static constructs, () “overloading”,…) when it has already been published? Changing such stuff radically would break a lot stuff around already, not to mention piss of the current followers, who like the constructs?

As the language stands right now, it seems to me, that it is a bit too different, from what the masses will jump onto. A big part of this is all the functional stuff. When clever people say, that the next big language will be functional, I tend to disagree. Maybe they are right, when you think about what we need to be able to write faster programs for the many cores of the future. But I think they are missing the migration path from the current big language (Java) to the upcoming one. I can’t really figure out if it is just me, that is getting old

(1 until 1000).filter(n => n % 3 == 0 || n % 5 == 0).foldLeft(0)(_ + _)

lazy val fib: Stream[Int] = Stream.cons(0, Stream.cons(1, fib.zip(fib.tail).map(p => p._1 + p._2)))

These examples are from http://scala-blogs.org/2007/12/project-euler-fun-in-scala.html. They illustrate that it’s not enough to know what arguments a method or function takes. You have to know the “special details”, like what the underscores do in foldLeft and what to do p._1 and p._2 mean. Take a look at the docs for p._1 at http://www.scala-lang.org/docu/files/api/scala/Product2.html#_1. (They weren’t too helpful for me) BTW, if you picked Scala right up then I bow down before you.

Dead on with the docs comment though. I was able to get on by myself more or less using an interactive Scala shell, the core scaladocs and the Scala wiki, but there were a few places that I just couldn’t fight my way through the woods. That’s when you contact your local scala expert (in my case Alex Blewitt) and beg advice. It’s something the Scala language community really needs to work on though. Too much of the “documentation” is just left up to the imagination and ingenuity of the developer.

I think your point is that when developers see “a + b” they presume it means what it means in mathematics and they cannot be shaken from that presumption. They presume that this operator has all the qualities of the ‘+’ operator with numeric operands, i.e. associative, communicative, transitive and symmetric qualities in addition to the summation behaviour. Not all implementations of operator + shared these qualities and so developers made incorrect assumptions. Reuse of the + name for an operation therefore is more dangerous somehow than reuse of the name ‘plus’ instead.

Elliot Rusty Harold thinks about the same: http://cafe.elharo.com/java/operator-overloading-considered-harmful/

Checkout Bruce Eckel’s rebuttal on that page. He starts with: “Unfortunately, Gosling did not seem to understand the actual problems with operator overloading in C++, and so he condemned it out of hand. People have been echoing this condemnation ever since.” Bruce says the real problem of operator overloading was complexity of implementation due to memory management concerns.

So, since scala is not C++, and does not have these memory issues, maybe scala developers have an opportunity that Java developers don’t have: to see the good side of operator overloading when its appropriate.

By the way, scala helps the developer with respect to precedence. If a method name starts with a ‘*’ then it has the precedence of a ‘muliplication’. If a method name starts with ‘+’, it has the precedence of an ‘addition’, and so on. So problems with precedence won’t be so easy to implement in scala.

Personally, I like operator overloading.

Regards,
John