Ciao Claudio! I understand and agree with you about your doubts - I don't have a strong idea, anyway I wouldn't take the *Handler as first choice, since it does not drive users to an event-handler alike programming model, rather *Operations makes more sense...
Let's take some time to think about it, excellent catch anyway :) best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Feb 11, 2012 at 8:53 PM, Claudio Squarcella <squar...@dia.uniroma3.it> wrote: > Hi, > > >> Maybe one last effort can be made to come up with more understandable >> names (e.g. for a user that does not know what a Semigroup or Monoid is). >> Suggestions are welcome. > > > I exhume this thread because I am still convinced that the "weight > architecture" would benefit from a bit of renaming. It is probably not the > case to touch mathematical concepts (Semigroup, Monoid), but rather the > actual implementations and/or variable names. Consider that with the current > fluent API the user has to deal with this stuff explicitly, specifying the > appropriate "handler" for weights. > > So for example all primitive implementations[1] would change their name from > FooWeight to something like FooWeightHandler, or FooWeightOperations, or > something like that. Variable names (like in [2]) would change from e.g. > orderedMonoid to weightHandler, weightOperations, etc. > > Any preference? > > Ciao > Claudio > > [1] > http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/weight/primitive/ > [2] line 64: > http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/shortestpath/DefaultShortestPathAlgorithmSelector.java?view=markup > > > -- > Claudio Squarcella > PhD student at Roma Tre University > E-mail address: squar...@dia.uniroma3.it > Phone: +39-06-57333215 > Fax: +39-06-57333612 > http://www.dia.uniroma3.it/~squarcel > > > --------------------------------------------------------------------- > 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