Hi Cloud/IO :) > * Doubles can also be multiplied, but so far we did not need to > include that in our stack of operations and properties. If we ever > need to do so, it will be enough to create another interface > extending OrderedMonoid and change the implemented interface in > DoubleWeightOperations.
isn't it a different monoid? I mean, multiplier operator, the 1 identifier and real numbers are a monoid, or my math became terribly bad? :P > * Also, there might be properties and/or operations that are unrelated > to each other, hence DoubleWeightOperations might implement more > than one interface in the future. that sounds good, anyway before to apply any potential improvement because "users may need of XXX" I'd want to make sure that custom behaviors can be applied to our APIs just estending existing component, rather than blindly provide potential features we don't need. I mean... if we do have the real need of having more operations than the OrderedMonoid already provides, so go for it; otherwise, users shall be able to define their on *Operator by extending ours and implementing their custom interface. I would be to support the minimum extensible set of features rather than supporting all the potential cases, unless we really have the practical need of them to implement new algos. Thoughts? -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Feb 19, 2012 at 2:59 PM, Claudio Squarcella <squar...@dia.uniroma3.it> wrote: > Hello Simone, > > >> It would be much more naturally to my hears hearing it as >> BigDecimalOrderedMonoid, doesn't it? > > > you have a valid point. However my intention is to decouple implementations > from underlying interfaces, because they might evolve and grow over time. > > Let me give you two examples: > > * Doubles can also be multiplied, but so far we did not need to > include that in our stack of operations and properties. If we ever > need to do so, it will be enough to create another interface > extending OrderedMonoid and change the implemented interface in > DoubleWeightOperations. > * Also, there might be properties and/or operations that are unrelated > to each other, hence DoubleWeightOperations might implement more > than one interface in the future. > > How does that sound? > > 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
