Hi Simone and all,
good to see activity on commons-graph :-)
I am currently using it for a research project in my lab, so hopefully
I'll be able to come back with more feedback. In the meantime I agree
with what you guys wrote so far.
Cheers,
Claudio
On 26/05/2013 20:46, Simone Tripodi wrote:
Hi Rodion,
Might the API look like this?
[...]
more or less :) Introducing kind of "PathFinder" interface, as main
entry point for shortest path algorithms, but keeping the current chin
builders - as you notice, `withEuristhic` makes sense for A* only,
when current fluent interfaces drive users on choosing the right
algorithm, with right inputs, via a "state-machine" which is clever
than a simple builder pattern.
Anyway
This would seem like eliminating the need for CommonsGraph -monolith at the
cost of introducing new interfaces/abstract base classes for every type of
algos out there, plus the actual implementation classes implementing the
API.
you got the idea, nice to see we are on the same path!!! :)
I'll prepare a more concrete proposal in a branch, hope to read
reviews from your side! :)
All the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, May 26, 2013 at 6:10 PM, Rodion Efremov
<rodion.efre...@cs.helsinki.fi> wrote:
Simone Tripodi kirjoitti 26.05.2013 18:35:
Hi all, mates,
after a long while I haven't touched commons-graph, I had the
opportunity to get influenced by some activities at my paid work that
made me think twice on what as been already done in that component,
and would like to bring new experiences in.
So, what I still like about it:
* graph APIs: the use of generics make the usage of graphes
extensible and adaptable;
* fluent APIs: this is the most powerful feature IMHO that simplifies
the APIs usage;
What I *don't* like anymore:
* poor modularization: commons-graph is ATM a big fat monolith;
* one single entry-point; for each new family of algorithm(s), new
methods have to be added in the main Commons-Graph class.
What I would like to propose to work _in a separated branch_, is
trying to split the big monolith in smaller modules and separate APIs
from related implementation as much as possible.
Questions are:
* WDYT? :)
Might the API look like this?
public interface PathFinder<V, E, W> {
public Path<V, E> search();
public PathFinder<V, E, W> from( V source );
public PathFinder<V, E, W> to( V target );
public PathFinder<V, E, W> withHeuristic( HeuristicFunction<V, W> f );
// for A* search.
}
... and then we would have, say, A* as follows:
public class AStarFinder<V, E, W> implements PathFinder<V, E, W> {
public Path<V, E> search() {
// A* magic here.
}
... implement the rest.
}
... with usage as follows:
Path<V, E> path = new AStarFinder<V, E, W>().withHeuristic( myFunkyHeuristic
).from( source ).to( target ).search();
This would seem like eliminating the need for CommonsGraph -monolith at the
cost of introducing new interfaces/abstract base classes for every type of
algos out there, plus the actual implementation classes implementing the
API.
* About release process: would it be acceptable, here in commons,
release a single module - the only one that has been changed, I mean -
without releasing the whole project?
* In case the answer to previous question is "no", would it make
sense moving commons-graph to the Incubator (and possibly to TLP)?
TIA, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
Claudio Squarcella
PhD student at Roma Tre University
http://www.dia.uniroma3.it/~squarcel
http://twitter.com/hyperboreans
http://claudiosquarcella.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
