Hi guys, > * 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. for a graph that uses a custom weight's type, the user can use the findMaxFlow( graph ).from( a ).to( g ).applying<Algorithm>( OrderMonoid ) ) API. WDYT ? ciao -- Marco Speranza <marco.speranz...@gmail.com> Flickr: http://www.flickr.com/photos/marcosperanza79/ Google Code: http://code.google.com/u/marco.speranza79/ Il giorno 12/feb/2012, alle ore 21:20, Claudio Squarcella ha scritto: > Hi Simone, > >>> Would it be so terrible to maintain such redundancy? >> IMHO, yes, because: >> >> * it has to be applied in each class of algorithms we support; >> >> * switching to proposed APIs, would proliferate that APIs in each algorithm; >> >> * weight types are driven by generics, so users cannot bind wrong >> weight monoid already at compile time. >> >> more proposals? :) > > ok fair enough, you were quite convincing :) > > Before giving up, one more alternative: > > * 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. > > Note: I don't want to over-engineer, I would just like the user not to > specify default *Operations, because that is also redundant from his/her > point of view. > > Ciao and thanks, > 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 >
smime.p7s
Description: S/MIME cryptographic signature
