I have recently completed a GTP communication layer of
my Go program and found it to be surprisingly simple and easy to do. I
figured I would share the design used with you in case you were thinking about
implanting the GTP in the near future, though this only applies to managed
languages (C#, VB.NET, Java, etc.) PLEASE DO NOT RESPOND TO THIS EMAIL
TALKING ABOUT PROGRAMMING LANGUAGES.
The Problem and
Requirements
When designing my GTP layer I wanted it to be as
simple as possible so that adding and removing commands wouldn’t be
troublesome. This ruled out using inheritance or a massive switch
statements. The main thing I kept running into was how do you keep the
list of known commands up to date at compile time without headache. If
you needed to know the function names at compile time the best I could come up
with was a hash table of command name / delegate (function pointer)
pairs.
However, in a moment of clarity I looked to reflection
and found the answer.
Here is the Idea:
public class Communicator
{
private GoEngine m_goEngine;
public GTPOutput protocol_version (GTPInput input){
}
public GTPOutput name (GTPInput input){ }
public GTPOutput clear_board (GTPInput input){ }
…
}
The communicator class has an instance of the
computer-Go engine which it instantiates in its constructor and every function
in the class is the implementation of a GTP command. So the
‘clear_board’ method is the implementation for the ‘clear_board’ GTP
command.
public class Driver
{
GTPOutput ExecuteCommand(string command, string arguments, string id =
“”);
}
When a driver class is created it uses reflection to
query all public methods in the Communicator class and then simply matches a
command string with a method name and calls the function. By doing this
you 1.) know every GTP function your Go program supports without having to
update a list, database, hashtable, etc 2.) adding new or GTP commands is as
simple as adding new functions and 3.) the implementation is very
clean.
In one day I was able to support every GTP command in
the version 2 draft, which surprised me enough to tell all of you
J
The only caveat is that you must manually exclude all
functions that are off of System.Object, so you must remove .ToString(), .
GetHashCode(), etc… unless you want list_commands to say that that is a
valid command to your Go engine. Also worth nothing is that the
performance hit is minimal, since you only need to query the object for its
methods once and after that are just calling super-function-pointers of
sorts.
Anyways, if there are any .NET or Java programmers out
there who haven’t added GTP support to your Go-bots yet, this might be the
solution you were waiting for.
Thanks,
-Chris Smith