String representation issues

[GoogleCodeExporter]

All of the evaluation methods are now going to return a String, instead of an 
array of move/piece because it would save a lot of space.

The strings main symbols for classification are: 
'|' to seperate colours (note. white is always on left),
then going from largest to smallest: commas (and spaces dashes should the need 
arise). ',' ' ' '-'


So, looking through the methods, the string return value is either going to be 
a combination of: booleans, moves, or pieces.

That's why it has been decided to use the first character to identify it: b for 
boolean, m for move, p for pieces.

Here's sample string storage methods:
Booleans:

b true | true
white = true, and black = true
b true | false
white = true, black = false

Moves:

m 12-13-0 13-15-0, 56-58-0 58-61-0 61-63-0 | 12-13-0
White moves:
1. a. startsq = 12, endsq=13, mod = 0
   b. startsq = 13, endsq=15, mod = 0
2. a. startsq = 56, endsq=58, mod = 0
[...]
black moves:
1. a. startsq = 12, endsq = 13, mod = 0

Pieces:

p 12-0, 56-1 | 23-5

White pieces: pawn(0) at 12, rook(1) at 56
Black pieces: queen(4) at 23

Note. all position has been decided to be stored as base10 conversions of the 
hexadecimal, just so it would be easier to convert back.
If anyone knows how to convert String directly to hexadecimal, please tells us. 
(ex. 1e (string) to 1e (hex))

ISSUES:

So every method will return a string, and a manager will put these string 
values in a hash table (like an array of strings). One Issue right now is the 
identification of the strings. 

So for example, if it is a combination of pieces, are the pieces suppose to 
mean attacking pawn pieces or like backward pawn pieces or like trapped pieces?
1. we could have a 3 char identification method. so for example, trapped pieces 
would have an acronym like "trp"
ex. p trp piece1, piece2, etc | etc.

2. we can organize them in the hash table according to index. so for example, 
array[0] woudl be trapped, array[1] would be bkwrd pawns, and etc.
The problem with 2, is that we're not sure if that will cause us further 
debugging troubles later on, which would be frustrating. Open to discussion.

Original issue reported on code.google.com by [email protected] on 11 Aug 2011 at 4:59