Hola Claudio, the patch you mentioned was something I would have asked you, before or later :P
Since we are on topic: is there any particular reason why Zero.zero() can not be part of Semigroup interface? Or better: is there any benefit we can get from keeping Zero and Semigroup separated? TIA, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Feb 12, 2012 at 11:36 PM, Claudio Squarcella <squar...@dia.uniroma3.it> wrote: > Hi, > > >>> * the mapping between primitive types and their respective default >>> *Operations is known and kept somewhere (abstract class, etc); >>> * each algorithm specifies only once the set of primitive types that >>> it accepts; >>> * with a bit of magic (?) we combine the above to provide shortcuts to >>> the user. >> >> +1 >> >> I think that a mapper can be useful. >> we can create a default mapper between primitives and *Operations and add >> a void API like that >> findMaxFlow( graph ).from( a ).to( g ).applying<Algorithm>( void ). >> we can choose the correct Operation mappimng directly on the default >> constructor using our mapper. >> >> so for the primitives Integer, Double etc, the user doesn't have to >> specify anything. > > > I thought about something similar. But I finally see two downsides: > > * we would need to use reflection for generics or some better > alternative to actually understand the generic type of weight and > map it to the appropriate *Operations, > * we should throw an exception when non-primitive weights are > incorrectly passed without a handler. > > Now that I have a clearer picture in mind I'm almost convinced to give up... > > Anyway, expect a patch soon from me that at least incorporates suggestions > on new names for primitive implementations and variable names ;) > > Ciao, > > Claudio > > -- > Claudio Squarcella > PhD student at Roma Tre University > http://www.dia.uniroma3.it/~squarcel > http://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
