commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [Graph] the future of commons-graph and modularization
Date Sun, 26 May 2013 21:00:33 GMT
Hello Claudio!

nice to read that commons-graph has a real production use case! :)

So, don't worry about APIs breakage: as I mentioned, I'll prepare my
proposal in a separated branch, so you can continue using the current
codebase in your lab without breaking your build :P

Thanks a lot, have a nice day!
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 10:28 PM, Claudio Squarcella
<squarcel@dia.uniroma3.it> wrote:
> 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.efremov@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message