Monday, October 24, 2011

Java Swing MVC

It is said that the MVC in SWING is really MV/C. What this means it that most SWING components (Views) are pre-coupled with a default Model. The programmer only needs to add a Controller (EventListener) to it, to get it to a workable state.

While this is true for most cases, but usually only for simpler components, like JButton etc. The more complex components, like JTable, JTree or JList, require you to provide them with your own custom Model to get them to a fully functional state.

Reference: http://compsci.ca/v3/viewtopic.php?t=11199

Sunday, October 9, 2011

Actor v.s. STM

Actors are excellent for solving problems where you have many independent processes that can work in isolation and only interact with other Actors through message passing. This model fits many problems. But the Actor model is unfortunately a terrible model for implementing truly shared state. E.g. when you need to have consensus and a stable view of state across many components.

Software Transactional Memory (STM) on the other hand is excellent for problems where you need consensus and a stable view of the state by providing compositional transactional shared state. Some of the really nice traits of STM are that transactions compose and that it raises the abstraction level from lock-based concurrency.

Akka allows you to combine Actors and STM into what we call Transactors (short for Transactional Actors), these allow you to optionally combine Actors and STM provides IMHO the best of the Actor model (simple concurrency and asynchronous event-based programming) andSTM (compositional transactional shared state) by providing transactional, compositional, asynchronous, event-based message flows. You don’t need Transactors all the time but when you do need them then you really need them.


Saturday, October 8, 2011

When to use case classes ?

It is very important that all messages that will be sent around in the system are immutable. The Actor model relies on the simple fact that no state is shared between Actors and the only way to guarantee that is to make sure we don’t pass mutable state around as part of the messages.

In Scala we have something called case classes. These make excellent messages since they are both immutable and great to pattern match on.


class Person {  
   def tell { 
   println( "here's a little story ..." ) 
   } 
}  
val singingPerson = new Person with Singer 
singingperson.sing
def cast( p: Person ) {     
   p match {       
   case s: Singer => s.sing       
   case _ => p.tell    
   } 
}

"Let it crash" - Scala

The “let it crash” approach to fault/error handling, implemented by linking actors, is very different to what Java and most non-concurrency oriented languages/frameworks have adopted.
It encourages non-defensive programming. Don’t try to prevent things from go wrong, because they will, whether you want it or not. Instead; expect failure as a natural state in the life-cycle of your app, crash early and let someone else (that sees the whole picture), deal with it.

reference: http://akka.io/docs/akka/1.1.3/scala/fault-tolerance.html

Scala's Unit vs Java's void

The type of the result here is scala.Unit, which is Scala's analogue to void in Java. The main difference between Scala's Unit and Java's void is that Scala lets you write down a value of type Unit, namely (), whereas in Java there is no value of type void.
(In other words, just as 1, 2, and 3, are potential values of type int in both Scala and Java, () is the one and only value of type Unit in Scala. By contrast, there are no values of type void in Java.) Except for this, Unit and void are equivalent. In particular, every void-returning method in Java is mapped to a Unit-returning method in Scala.

scala> println("Hello, world!")
Hello, world!
unnamed2: Unit = ()