Hi Gary!!! :) I don't see any issue on adding the BST algorithms you need in [graph], even if you have to reuse the minimum amount of codebase, packages don't usually interact each other very much, unless some DFS/BFS or shortest path is needed in other algo.
I have the plan of adding KDTree searches as well. My personal vision of [graph] is realizing a graph-pedia of graph-related algorithms implementation, so every addition is more than welcome!!! The only kind request I have, if you could have a look at how we are trying to implement fluent APIs, and applying as well to BST. Looking forward to see your commits, thanks in advance and welcome in the brotherhood!! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Feb 1, 2012 at 5:20 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > Hi All. > > I've been looking for a place to experiment with BST code and [graph] seems > like a logical place since a BST is a directed graph. > > The issue I have is that I would like a o.a.c.graph.bst package but I do > not see re-using much of the [graph] infra aside from some very basic > interfaces. > > I do not want a [bst] project because eventually it should be possible to > morph a 'classic/light' BST into a 'heavy' [graph]. > > Thoughts? > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
