Question/remark on timeoutMove with agents implemented in java

Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.

Question/remark on timeoutMove with agents implemented in java
I’m implementing my agent for the Kalah competition in java and ran into some trouble with the timeoutMove variable. I’m sure this will be interesting for anybody who has never programmed in scala before like me:

I tried setting timeoutMove directly in the function move of my agent extending Agent without declaring it as a member variable like done in the scala code for RandomPlayer in the package, but this didn’t compile because apparently timeoutMove is private in Agent and therefore couldn’t be set by me in my agent.

I then created a member variable “public int timeoutMove” in my agent implementation but the value of this variable never made it to the game (probably the actual timeoutMove variable in Agent overshadowed it for the game or something; at least my agent would always pick the default value 1 in game although I clearly set the variable to other values).

The solution (at least what works) is instead of creating a variable “int timeoutMove” is to create a function “public int timeoutMove()” in the agent implementation that returns the value to be played when the agent times out.

So far concerning the remark. My question is: is this the intended way to handle the whole timing out problematic and is what I found suprising for someone familiar with scala?


I’m confused…

This is very surprising to me. By default, scala methods/values/variables are all public unless deliberately restricted in scope. Consequently, timeoutMove should be a public variable - as it has to be, because it is being read by the Game-class as well. In deed, in scala it works flawlessly. For example, RandomPlayer changes its timeoutMove, and since scala classes are compiled into standard java .class-files, I would have suspected that it should work just the same for java.

Have you tried „@override public int timeoutMove“? Anyway, good to know that you found a solution to the problem :slight_smile:


Another thing one could try is - I don’t know too much java - whether something like “super.timeoutMove” exists (at least that’s what it’s called in scala - “super” is basically “this” but restricted to the parent class) and to use that.


Two good suggestions! Unfortunately they both didn’t work. “@Override public int timeoutMove” didn’t compile; it probably isn’t valid java syntax. The “super.timeoutMove” unfortunately also didn’t compile because “timeoutMove has private access in info.kwarc.teaching.AI.Kalah.Agents.Agent”.

I might want to add that I’m compiling my java code with scala, maybe this makes a difference.

Also I got the idea to create a function instead of a variable from implementing my name and students variables. Implementing them with variables also didn’t work; the compiler errors were hinting at an expected function and not really understanding the scala documentation I just went with what the compiler told me it needed.


Access modifiers in Scala have little to do with access modifiers in Java. All attributes in Scala are private when accessed through Java, they have a getter whose name is the same as the one of the attribute, so in this case it would be timeoutMove(). If the attribute is mutable there is a setter called timeoutMove_=(value) in Scala. This is no valid name for a method in java however. Therefore the solution is obviously to call the method timeoutMove_$eq(x). If you know who made those design decisions, send them my regards.


With respect to java or scala? In the latter case, I’m assuming all of those were the „best“ options in trying to build an entirely new proper accessibility and class-inheritance architecture on top of the existing one from java… poor scala developers.

But now that they’ve done that I very much wonder why anyone would voluntarily use java when scala is obviously superior #don’tatme :smiley: