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)