Hi (and sorry for the late) I personally don't see the reason to be open to *Operations until *Monoid (actually, wrongly, *Weight) until there is the real need of.
Anyway, please share a patch in the issue you filled - code talks much better, I could finally see what I am currently missing ;) looking forward to it! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Feb 19, 2012 at 5:05 PM, Claudio Squarcella <squar...@dia.uniroma3.it> wrote: > Hi, > > >>> * 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 > > > you're right! Your math is cool don't worry :) > > But see, maybe we could let it implement both an "addiction monoid" and a > "multiplication monoid". We could even create Addition (and later maybe > Multiplication?) as interface extending Monoid, so that we also solve the > other aspect pointed out by Axel days ago: the Monoid would offer a generic > "applyOperation", while Addition would wrap it as "sum" (and Multiplication > as "multiply"). Cool? > > >>> * 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. > > > then we could use the pattern *WeightBaseOperations (e.g. > DoubleWeightBaseOperations): so that we developers are free to extend it > with more properties over time, as well as the users in their > implementations -- and the name is IMHO self-explanatory and unambiguous. > > In other words: Doubles (as well as the other types) are not *only* monoids. > So I feel we would be much more "blind" sticking to the term "monoid" in the > implementation: we need more flexibility, and I hope the above > *WeightBaseOperations sound good as a candidate. > > Thank you for the discussion, waiting for further input! > Claudio > > >> >> 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 >> > > -- > 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
