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

Reply via email to