Add more documentation

Also, changed my mind on the way DiePool and its implementations should
be structured. The implementations go in the die pool file as internal
classes, because nobody should particularly care the specifics about
their die pool, only that it does what it says it should

1 files changed, 21 insertions, 0 deletions

diff --git a/dice/src/example/java/bjc/dicelang/neodice/statements/StatementValue.java b/dice/src/example/java/bjc/dicelang/neodice/statements/StatementValue.java
index de796e5..d804a10 100644
--- a/dice/src/example/java/bjc/dicelang/neodice/statements/StatementValue.java
+++ b/dice/src/example/java/bjc/dicelang/neodice/statements/StatementValue.java
@@ -2,20 +2,41 @@ package bjc.dicelang.neodice.statements;
 
 import java.util.*;
 
+/**
+ * Represents a value for diebox, as a base class.
+ * @author Ben Culkin
+ *
+ */
 public abstract class StatementValue {
+    /**
+     * The type of the value.
+     * @author Ben Culkin
+     *
+     */
 	public static enum Type {
+	    /** The 'void' value. There is only one value of this type. */
 		VOID,
+		/** The 'boolean' type. There is one true value, and one false value. */
 		BOOLEAN,
+		/** Represents an integer. */
 		INTEGER,
 		
+		/** Represents a single die. */
 		DIE,
+		/** Represents a pool of dice. */
 		DIEPOOL,
 		
+		/** Represents an array of some type. */
 		ARRAY,
 	}
 	
+	/** The type of this value. */
 	public final Type type;
 	
+	/**
+	 * Create a new statement value.
+	 * @param type The type of the value.
+	 */
 	protected StatementValue(Type type) {
 		this.type = type;
 	}