gistfile1.txt

# Looking to reduces rows of board game data to
# primitives (for eventual JSON output).

# each cell can be either unoccupied, or occupied by N 
# armies of a given color. What data format do you prefer,
# and why?
#----------------------------------------------------------

# 1) nil indicates empty territory
[[:white, 2], nil, [:black, 3]] 

# 2) :empty indicates empty territory
[[:white, 2], :empty, [:black, 3]] 

# 3) somewhat homogenous. nil indicates count being non-applicable
[[:white, 2], [:empty, nil], [:black, 3]] 

# 4) fully homogenous. 0 indicates no units of either color present
[[:white, 2], [:empty, 0], [:black, 3]] 

# your own representation (leave a note in the comments)

@phiggins: Interesting ideas, thanks for sharing. The board is an NxN grid, so an array of arrays makes sense for this game.

The context is important, but it's okay to assume it's a generic board in which cells can be empty, or have n cells of a given color (either white or black)

Maybe you should look at using a class for each cell. At that point it would be easier to extend and add other information or maybe some behavior to a cell. You could also make it more clear with intention reviling method name. I have often wanted to add unary operators to game cells.

Not to go all "appeal to authority" on you, but I just read this last night, and thought it worth mentioning:

The more code we write, the more we're convinced that we should define types to represent value concepts in the domain, even if they don't do much. It helps to create a consistent domain model that is more self-explanatory. If we create, for example, an Item type in a system, instead of just using String, we can find all the code that's relevant for a change without having to chase through the method calls. Specific types also reduce the risk of confusion -- as the Mars Climate Orbiter disaster showed, feet and metres may both be represented as numbers but they're different things. Finally, once we have a type to represent a concept, it usually turns out to be a good place to hang behavior, guiding us towards using a more object-oriented approach instead of scattering related behavior across the code.

-- Growing Object Oriented Software, Guided by Tests

@adkron, @arwagner: I am using a class for each cell, I just need to reduce things to primitives for serialization purposes.

In that case I would go with number 4. I like constancy in my data and api. If the empty cells are going to take up too much space then I would go with 1 to save space.

I go for #4, after all the advantages already said, I'd add the self-documented style.

As you said is a serialization structure what we are defining here, so would be possible to think it is gonna be drunk up by external systems, better then that the info has an implicit way to be understood.