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/DiePoolStatementValue.java b/dice/src/example/java/bjc/dicelang/neodice/statements/DiePoolStatementValue.java
index 8d7c1f4..114475c 100644
--- a/dice/src/example/java/bjc/dicelang/neodice/statements/DiePoolStatementValue.java
+++ b/dice/src/example/java/bjc/dicelang/neodice/statements/DiePoolStatementValue.java
@@ -6,10 +6,23 @@ import java.util.*;
 
 import bjc.dicelang.neodice.*;
 
+/**
+ * A StatementValue that represesnts a die pool
+ * @author Ben Culkin
+ *
+ */
 public class DiePoolStatementValue extends StatementValue {
+    /** The type of the contained value. */
 	public final Type elementType;
+	/** The die pool itself. */
 	public final DiePool<StatementValue> value;
 	
+	/**
+	 * Create a new diepool value.
+	 * 
+	 * @param elementType The contained type.
+	 * @param value The die pool itself.
+	 */
 	public DiePoolStatementValue(Type elementType, DiePool<StatementValue> value) {
 		super(DIEPOOL);