I like some of the ideas behind Scala but so far have found its syntax to be, shall we say, less than elegant.

If your Java class has ’statics’, you will be obliged to split your class in two:
(a) one part which is similar to a Factory pattern, which contain non-static methods which were static methods in your original class and
(b) another part which contains all non-static methods of your original class.

In other words, you have to create the concepts of Scala class and the companion Scala object by hand, in Java. You have to do that when you are about to implement your application on top of OSGi, possibly breaking source compatibility with another platforms.

So, we can see that Scala is very well suited to OSGi because it ‘forces’ developers to adopt a recommended strategy which is “get rid of statics” from day one.

In particular, statics are ugly because they do not scale well and they jeopardize concurrent threads. If statics do not ’scale’ well, they cannot be part of Scala

Scalability problems are certainly irrelevant with small applications but they are critical in the real world, when big and complex applications are needed in order to perform useful work, attending thousands or millions of requests a day.

Scala was designed trying to address needs not only of professional developers but also addressing needs of huge, complex applications, running on enterprise grade environments.

Thanks

Richard Gomes

I have found your articles on Scala helpful. Thank you for writing them. However I have noticed an error in this post. You state that closures and anonymous methods are the same thing. The following sentence confused me:

This “returnless” form becomes extremely important when dealing with anonymous methods (closures).

In fact they are not the same. From Wikipedia:

“The term closure is often mistakenly used to mean anonymous function. This is probably because most languages implementing anonymous functions allow them to form closures and programmers are usually introduced to both concepts at the same time. These are, however, distinct concepts.”

See http://en.wikipedia.org/wiki/Closure_%28computer_science%29 for more.

… it just seems like overkill to me ( to require a singleton class for this ). Hmmm …

abstract class CanLog(name: String) {
  val logger = Logger getLogger name
}

Then, for each class for which you want to allow logging, declare the companion object as a subclass of CanLog. Thus, for some class DataBean, declare the class normally and then define the following additional snibblet:

object DataBean extends CanLog("mypackage.DataBean")

With this in place, you can safely get the static logger using “DataBean.logger” (without the quotes). That logger will indeed be static across the entire JVM just like a true Java static.

private static final Logger logger = Logger.getLogger(….the class .getName()… );

Do you have any suggestions on how do you do this in Scala?

Note: I’ve googled/heard (could be wrong) that static final ‘values’ … can become static fields … but Logger is not a value type.

Cheers, Rob.

PS: Nice work with your Scala articles – thanks for your efforts !!

Thanks for putting in the time to respond, Daniel.

your example

package com.codecommit.mypackage

class MyClass {
private[com.codecommit.mypackage] def myMethod = “test”
}

is not working for me…The compiler complains about the first dot after “com”. However, if I only put “mypackage” for AccessQualifier, it works like charm.