Scala Switch...I mean Match Case

The syntax here is different than Java and the trickiest part was finding out that the default (fall back) case is defined by the underscore character:

 

def matchTest(x: Int): String = x match {
     case LIGHT => "LL "
     case LIGHT_KING => "LK "
     case DARK => "DD "
     case DARK_KING => "DK "
     case _ => "-- "
    }

In Scala, you define the match case as a method with a return value. If you want to execute the match case, you simply create a var and say: var = matchTest(integerValue).

This will evaluate the match case and either assign a matched value OR fall back on the default case _.

Scala Method Syntax

Scala was a little tricky at first, as I got errors when I tried to rely solely on my Java knowledge.

def isLegalMove(x1:Int, y1:Int, x2:Int, y2:Int): Boolean = {code here}

def - this tells Scala that we are defining a method

parameters - these must have the pattern name:type

return value: this follows the parameters, and must be preceded by a colon. if there is no return value, then you follow the parameters with an equals sign

method body: comes after the return value, preceded by an equals sign

Exceptions

Scala exception handling is very similar to Java. Here is how it is handled:

try{
doSomethingHere()
} 
 catch { 
case e:Exception => handleExceptionHere()
}

Validating user inputs… oh no you didn’t!

One of the challenges we decided to take on in this project is to allow the user to interact with the game through the console. This was not something that was in the original Java version, so it involved a bit more than just porting over code from one language to another.

Allowing the user to enter information means that validation was going to be necessary. Like many other languages, Scala allows for the use of regular expressions as a common way to check data. However, there are a few implementations that Scala allows for which are not typical in other languages.

 

Pattern emailParser = Pattern.compile("([\\w\\d\\-\\_]+)(\\+\\d+)?@([\\w\\d\\-\\.]+)"); 

String s = "zippy@scalaisgreat.com"; 
Matcher m = emailParser.matcher(s); 
if (m.matches())
{
    String name = m.group(1);
    String num = m.group(2);
    String domain = m.group(3); 

    System.out.printf("Name: [%s], Num: [%s], Domain: [%s]\n", name, num, domain);
} 

//**********************************// 

val EmailParser = """([\w\d\-\_]+)(\+\d+)?@([\w\d\-\.]+)""".r 
val s = "zippy@scalaisgreat.com" 
val EmailParser(name, num, domain) = s 
printf("Name: %s, Domain: %s\n", name, domain) 

//**********************************// 

if (Pattern.compile("\\d+").matcher("abc 123 @#$").find) println("ok")

The following format was used in our implementation to take in the user input on the command prompt and validated it using Regular Expressions:

def readConsole{
 			println("Type \"Quit\" if you would like to end the game")
 			println("Enter position to move from and to in \"[A-H][1-8] [A-H][1-8]\" format:")
 			val positionParser = "([A-H])([1-8]) ([A-H])([1-8])".r
 			val s = Console.readLine
			
			s.toUpperCase match {
				// check user entered position in (Col1, Row1, Col2, Row2) format
				case positionParser(cy1, cx1, cy2, cx2) => {
				print("You entered to move from ")
				printf("Col:%s Row:%s to Col:%s Row:%s", cy1, cx1, cy2, cx2)
				println
				
				// convert user entered X values to int
				val x1 = cx1.toInt
				val x2 = cx2.toInt
			
				// lookup the user entered values for Y and find their respective position in colConversionArray
				val y1 = colConversionArray.indexOf(cy1)+1
				val y2 = colConversionArray.indexOf(cy2)+1
				
				makeMove(y1, x1, y2, x2
			)
		}
		
		// If user enters 'quit' (case insensitive), then sets the userQuit flag to true and prints message
		case "QUIT" => {
			userQuit = true
			println("Thanks for playing Scala Checkers!")
		}
		
		// Catch all non-matching entries
		case _ => println ("Incorrect position, try again")
}

Git'er done... or not

// Note to the reader: Although the primary purpose of this blog is to keep a running dialog of lessons learned and pros/cons of the Software Paradigm project, it almost seemed necessary to include some of the general team experience as well.

Having been out of the pure development world (professionally) for a while, it's always fun to get back into the roots of where I began. Through the progression of this course, we ended up writing code for assignments that needed to be submitted to a centralized location for the professor to grade. The version/source control system Git (and its subsequent site GitHub.com) was the chosen method to use.

While the learning curve was not too high in getting things running with Git, most of the options of usage were limited to the command-line world (nothing wrong with that, so far). As long as it was a one way interaction (i.e., 1 student pusing their code/homework up to one Github repository), things were working with minor issues.

However, as the team project phase began, it became quite apparent that there were issues with Git, at least in our usage of it. With our team of 3, we found that multiple people working on files started to produce some errors through Git along with conflicts that didn't seem to be easiliy resolved. The lack of a GUI took out some checks and balances which started to increase with every change that was made.

Certain errors started to creep up consistently, such as the infamous:

error: Untracked working tree file '/path/to/some/file.scala' would be overwritten by merge.

The only resolution that would work was to completely delete your entire local working version of the entire project, and do a clean git clone from the server. Obviously, this was not a solution that could be maintained, but just a quick troubleshooting technique as you could not actually work on anything because you had to completely wipe your files just to download the updates made by your teammates.

There also was no consistency between systems or people in getting these errors. A wide variety of environments are being used by the entire team from Windows XP/7 to Ubuntu and other flavors of Linux with similar results.

After much frustration, the team came to a unanimous decision to port over the entire project to Google Code, which utilized the SVN source control system. With easy integration into all flavors of environments that the team is using, we were able to find SVN client tools and have been working on the actual project since, instead of managing the source control aspect.

It looks like some tools might be well suited for the solution, but if the troubleshooting curve is much larger and ineffective than the actual goal, then alternatives will have to be visited.

For loop iteration in Scala

The Scala for loop notation:

for (i<-0 until some.length)

basically means, in java-ish code:

for (int i=0; i < some.length; i++)

So, the reason we were only getting a 7x7 board was because Scala iterates using the "until" as non-inclusive to the some.length (i.e. less than).

Val vs Var

Just did some research on this....

val is used for immutable values (those which cannot be changed *cough* Java final variables)

var is mutable.