Re: [graph][discuss] possible room for improvement for Visit handler APIs
that's great indeed, thanks for taking care! :) I just added a comment as well, looking forward to hear from you! all the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Mar 26, 2012 at 12:15 AM, Claudio Squarcella squar...@dia.uniroma3.it wrote: Hi, On 25/03/2012 23:45, Simone Tripodi wrote: just filled SANDBOX-416 and committed the org.apache.commons.graph.visit.VisitState enum, now I am too sleepy to continue - feel free to finalize it if you want/can/have spare time/... I did that, see the comment on SANDBOX-416 :) Ciao, Claudio all the best and thanks for discussing, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Mar 25, 2012 at 11:36 PM, Claudio Squarcella squar...@dia.uniroma3.it wrote: Hi, On 25/03/2012 23:27, Simone Tripodi wrote: just had an idea of a possible new state: SKIP,that would mean skipping the children/subtrees... thoughts? :P +1. Of course we still need to document the whole thing in the javadoc (as we did already with boolean values), but the readability of the code is a clear advantage. Thanks, Claudio -- Claudio Squarcella PhD student at Roma Tre University http://www.dia.uniroma3.it/~squarcel http://twitter.com/hyperboreans http://claudio.squarcella.com/ - 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://claudio.squarcella.com/ - 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
[graph][discuss] possible room for improvement for Visit handler APIs
Hi Graphers, I was trying to code the ELO algorithm using a BSF algo and got in trouble with the boolean return value of the visit handler methods - I think that we could improve it a little, adopting a similar approach of the AsyncHttpClient's AsyncHandler[1]: *maybe* having those methods that return a kind of STATE[2] enumeration would make APIs a little more intuitive. WDYT? TIA, -Simo [1] http://sonatype.github.com/async-http-client/request.html [2] http://sonatype.github.com/async-http-client/apidocs/reference/com/ning/http/client/AsyncHandler.STATE.html 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
Re: [graph][discuss] possible room for improvement for Visit handler APIs
Hi Simone, On 25/03/2012 22:46, Simone Tripodi wrote: Hi Graphers, I was trying to code the ELO algorithm using a BSF algo and got in trouble with the boolean return value of the visit handler methods - I think that we could improve it a little, adopting a similar approach of the AsyncHttpClient's AsyncHandler[1]: *maybe* having those methods that return a kind of STATE[2] enumeration would make APIs a little more intuitive. WDYT? if I get it right you are saying that two values (true/false) are too limiting for some of the current methods. Do you have a specific example, to get a clearer idea of the improvement? Thanks, Claudio TIA, -Simo [1] http://sonatype.github.com/async-http-client/request.html [2] http://sonatype.github.com/async-http-client/apidocs/reference/com/ning/http/client/AsyncHandler.STATE.html 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 -- Claudio Squarcella PhD student at Roma Tre University http://www.dia.uniroma3.it/~squarcel http://twitter.com/hyperboreans http://claudio.squarcella.com/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [graph][discuss] possible room for improvement for Visit handler APIs
if I get it right you are saying that two values (true/false) are too limiting for some of the current methods. Do you have a specific example, to get a clearer idea of the improvement? nope, I am saying that the boolean flag is less intuitive - I had to take a (short, of course) while to realize the meaning, if returning `true` meant `stop it` or `continue it`. Yes, maybe I am already sleeping and that yesterday's TZ switch doesn't help, but if it happened to someone with hands on [graph], I wonder if that could happen to users as well. My proposal is switching to a more expressive values, kind of VisitState.(ABORT|CONTINUE) enumeration that is free of any misunderstanding. Thoughts? best and thanks, -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
Re: [graph][discuss] possible room for improvement for Visit handler APIs
Hi, My proposal is switching to a more expressive values, kind of VisitState.(ABORT|CONTINUE) enumeration that is free of any misunderstanding. Thoughts? ok so something like: * if ( handler.finishEdge( prevHead, e, v ).equals( VisitState.ABORT ) ) .. Looks good to me, +1 :) Ciao, Claudio best and thanks, -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 -- Claudio Squarcella PhD student at Roma Tre University http://www.dia.uniroma3.it/~squarcel http://twitter.com/hyperboreans http://claudio.squarcella.com/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [graph][discuss] possible room for improvement for Visit handler APIs
* if ( handler.finishEdge( prevHead, e, v ).equals( VisitState.ABORT ) ) .. even better: VisitState.ABORT == handler.finishEdge( prevHead, e, v ) Looks good to me, +1 :) great, I am going to change it - then sleeping to cheat the new TZ :P best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Mar 25, 2012 at 11:15 PM, Claudio Squarcella squar...@dia.uniroma3.it wrote: Hi, My proposal is switching to a more expressive values, kind of VisitState.(ABORT|CONTINUE) enumeration that is free of any misunderstanding. Thoughts? ok so something like: Ciao, Claudio best and thanks, -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 -- Claudio Squarcella PhD student at Roma Tre University http://www.dia.uniroma3.it/~squarcel http://twitter.com/hyperboreans http://claudio.squarcella.com/ - 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
Re: [graph][discuss] possible room for improvement for Visit handler APIs
just had an idea of a possible new state: SKIP,that would mean skipping the children/subtrees... thoughts? :P -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Mar 25, 2012 at 11:22 PM, Simone Tripodi simonetrip...@apache.org wrote: * if ( handler.finishEdge( prevHead, e, v ).equals( VisitState.ABORT ) ) .. even better: VisitState.ABORT == handler.finishEdge( prevHead, e, v ) Looks good to me, +1 :) great, I am going to change it - then sleeping to cheat the new TZ :P best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Mar 25, 2012 at 11:15 PM, Claudio Squarcella squar...@dia.uniroma3.it wrote: Hi, My proposal is switching to a more expressive values, kind of VisitState.(ABORT|CONTINUE) enumeration that is free of any misunderstanding. Thoughts? ok so something like: Ciao, Claudio best and thanks, -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 -- Claudio Squarcella PhD student at Roma Tre University http://www.dia.uniroma3.it/~squarcel http://twitter.com/hyperboreans http://claudio.squarcella.com/ - 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
Re: [graph][discuss] possible room for improvement for Visit handler APIs
Hi, On 25/03/2012 23:27, Simone Tripodi wrote: just had an idea of a possible new state: SKIP,that would mean skipping the children/subtrees... thoughts? :P +1. Of course we still need to document the whole thing in the javadoc (as we did already with boolean values), but the readability of the code is a clear advantage. Thanks, Claudio -- Claudio Squarcella PhD student at Roma Tre University http://www.dia.uniroma3.it/~squarcel http://twitter.com/hyperboreans http://claudio.squarcella.com/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [graph][discuss] possible room for improvement for Visit handler APIs
just filled SANDBOX-416 and committed the org.apache.commons.graph.visit.VisitState enum, now I am too sleepy to continue - feel free to finalize it if you want/can/have spare time/... all the best and thanks for discussing, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Mar 25, 2012 at 11:36 PM, Claudio Squarcella squar...@dia.uniroma3.it wrote: Hi, On 25/03/2012 23:27, Simone Tripodi wrote: just had an idea of a possible new state: SKIP,that would mean skipping the children/subtrees... thoughts? :P +1. Of course we still need to document the whole thing in the javadoc (as we did already with boolean values), but the readability of the code is a clear advantage. Thanks, Claudio -- Claudio Squarcella PhD student at Roma Tre University http://www.dia.uniroma3.it/~squarcel http://twitter.com/hyperboreans http://claudio.squarcella.com/ - 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
Re: [graph][discuss] possible room for improvement for Visit handler APIs
Hi, On 25/03/2012 23:45, Simone Tripodi wrote: just filled SANDBOX-416 and committed the org.apache.commons.graph.visit.VisitState enum, now I am too sleepy to continue - feel free to finalize it if you want/can/have spare time/... I did that, see the comment on SANDBOX-416 :) Ciao, Claudio all the best and thanks for discussing, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Mar 25, 2012 at 11:36 PM, Claudio Squarcella squar...@dia.uniroma3.it wrote: Hi, On 25/03/2012 23:27, Simone Tripodi wrote: just had an idea of a possible new state: SKIP,that would mean skipping the children/subtrees... thoughts? :P +1. Of course we still need to document the whole thing in the javadoc (as we did already with boolean values), but the readability of the code is a clear advantage. Thanks, Claudio -- Claudio Squarcella PhD student at Roma Tre University http://www.dia.uniroma3.it/~squarcel http://twitter.com/hyperboreans http://claudio.squarcella.com/ - 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://claudio.squarcella.com/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
