TODO in axiom-0.1.1 vs TODO in axiom-0.2.0
- old
+ new
@@ -1,18 +1,24 @@
* TODO:
+* Create a module to allow methods to be added to existing Attribute objects
+ in such a way that the same methods can be easily mixed into other
+ things, like functions or relations.
+ * Replace the explicit mix-into-relation with something that adds the
+ methods to Axiom::Attribute::Relation, and then have Axiom::Relation
+ "inherit" those by declaring it's own relation methods as being of that
+ type.
+
+* Move all Axiom::Algebra classes under Axiom::Relation::Operation
+
* Change Algebra::Extension#extensions to be a non-primtive
* May also change EvaluationContext#functions to return a set of functions.
* Add key minimization to Header
* When unioning two keys together it is really simple to end up
with indexes that overlap and cause an exception.
-* Add Header#size
- * Replace code that coerces the Header to an Array in order to get the size
- with Header#size.
-
* Make Equalizer handle subclasses without having to specify the attribtues
again in each descendant.
* Allow Evaluator::Context to be used like:
@@ -32,45 +38,32 @@
* Make sure the Tuple has a class level method called #header that returns
the set of attributes.
* Use a class variable to store each "Tuple class" so that anything with a
similar header will be reused.
-* Remove mean/variance/stddev modules from Virtus::Attribute::Comparable
- * It makes no sense for comparable objects to be "averaged", what would it
- mean to get the average string?
-
-* Remove Order, Reverse, Limit and Offset from the Relation inheritance chain
+* Remove Sorted, Reverse, Limit and Offset from the Relation inheritance chain
* Instead make it so they are proxy classes that wrap Relations, but
proxy method calls to the Relation methods, and then wrap the return
value (assuming it's a Relation) in a copy of itself.
* Also this will allow knowledge of #directions to be removed from
all the Relation classes. Only the Ranking classes will need to know
about directions.
* The Reverse class will probably not be needed either. All we need is
- for the #reverse method to create a new Order with the directions
+ for the #reverse method to create a new Sorted with the directions
reversed.
* Remove the knowledge of directions from materialized relations
- and instead wrap materialized relations in the Order object
+ and instead wrap materialized relations in the Sorted object
if any.
-* Add Relation#group and Relation#ungroup
-
* Update Attributes so that constraints are modelled using predicates,
so that when "join-ability" is tested, the predicates can just be
compared for equality.
* Create an object that can wrap a predicate, and if it fails it will
set the object's error state, and then propagate the status to the
caller. This will allow a "complex" predicate to set the errors
on tuples, while still allowing all the same objects to be used.
-* Update memoization to take into account the arguments passed into
- the method. It should memoize differently for different
- methods. Perhaps it could have a special case for methods
- with a 0-arity vs n-arity methods, but it needs to handle cases
- like with #hash that accept no args, and #optimize that accepts
- 1 arg.
-
* Within the restriction context, make sure the attributes have aliases for:
* Alias #== to #eq (may break alot)
* Alias #!= to #ne (in 1.9 only)
* Alias #>= to #gte
* Alias #> to #gt
@@ -99,9 +92,14 @@
* none?
* many?
* include? / member?
* min / max / minmax (when the tuples are sorted)
-* Rename Order to Sorted
- * In other languages, "ordered" implies that the order tuples are added to the
- relation is tracked, while "sorted" means that they are sorted according to
- some criteria. The latter is closer to what is meant.
+* Add Axiom::Relation aggregate methods:
+ * count
+ * count(attribute)
+ * sum(attribute)
+ * minimum(attribute)
+ * maximum(attribute)
+ * mean(attribute)
+ * standard_deviation(attribute)
+ * variance(attribute)