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, 13 insertions, 0 deletions

diff --git a/dice/src/example/java/bjc/dicelang/neodice/statements/DieStatementValue.java b/dice/src/example/java/bjc/dicelang/neodice/statements/DieStatementValue.java
index f9a8d1e..5662a59 100644
--- a/dice/src/example/java/bjc/dicelang/neodice/statements/DieStatementValue.java
+++ b/dice/src/example/java/bjc/dicelang/neodice/statements/DieStatementValue.java
@@ -6,10 +6,23 @@ import java.util.*;
 
 import bjc.dicelang.neodice.*;
 
+/**
+ * A StatementValue that represents a die.
+ * @author Ben Culkin
+ *
+ */
 public class DieStatementValue extends StatementValue {
+    /** The type of values this die rolls. */
 	public final Type sideType;
+	/** The die itself. */
 	public final Die<StatementValue> value;
 	
+	/**
+	 * Create a new die StatementValue.
+	 * 
+	 * @param sideType The type of value this die rolls.
+	 * @param value The die itself.
+	 */
 	public DieStatementValue(Type sideType, Die<StatementValue> value) {
 		super(DIE);