2015-12-03 14:48 GMT+01:00 Ben Coman <[email protected]>: > On Wed, Dec 2, 2015 at 10:45 PM, Sven Van Caekenberghe <[email protected]> > wrote: > > > >> On 02 Dec 2015, at 15:21, Nicolai Hess <[email protected]> wrote: > >> > >> > >> > >> 2015-12-02 15:03 GMT+01:00 Ben Coman <[email protected]>: > >> On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <[email protected]> > wrote: > >> > Hi, > >> > > >> >> On Dec 1, 2015, at 5:13 PM, Max Leske <[email protected]> wrote: > >> >> > >> >> @Doru > >> >> You’re missing the point: #anyOne *fails* for empty collections. > >> > > >> > I am not missing the point at all. I am saying that if you want sum: > to be generic, it cannot assume a specific Zero object. > >> > > >> > And sum: should be generic because of its name. > >> > >> I am missing understanding the other use cases. Can you describe > >> further the generic nature of #sum & #sum: ? I would have thought by > >> default they only applied to numbers. > >> > >> sum can be applied to anything that supports #+, not only numbers > >> sum: can be applied to any collection with a block that return some > object that supports #+ > > To me this is a mis-application of polymorphism, that just because > something responds to #+ it should be summable. We have overloaded the > semantics of #+ to mean both numeric addition and > concatenation/membership, but technically "summation" relates only to > numeric addition. >
I didn't wanted to argue for or against any change. I just wanted to clarify that there are situations in which a generic sum/sum: that throws an error on empty collections and don't assume a null value makes sense. > > https://www.google.com.au/search?q=define+sum&oq=define+sum > https://www.google.com.au/search?q=define+concatenate&oq=define+concatenate > > For example... > > * KMModifier implements #+ so what is the expected semantic of " { > KMModifier shift . KMModifier meta} sum " ? > To me this is more of a concatenation/join/union facility rather than > numeric addition. (btw, that expression actually fails since > KMModifier does not understand minus #- ) . > > * String implements #+ and " { '1' . '2' } sum " --> '3', so > actually its doing numeric addition. However " { 'a' . 'b' } sum " > produces an error. > > So actually there seem some existing problems with summing > non-numerics. What examples work? > > * Trait classes implement both #+ and #- , but the semantic seems > more to do with membership than numeric addition. I don't how how to > produce an example of using #sum against traits. > > * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 + > 1 " --> 3@3 , so " {} sum " returning 0 would seem to not > cause any error in this case. > > > cheers -ben > > > >> > >> therefore you can not assume 0 (<- a number) is a proper initial value > therefore you *need* to work with #anyOne > >> and as you can not assume a proper initial value, you can not assume a > default value for empty collections > >> -> it should throw an error. If you (the caller of the function) knows > what to do with an empty collection you have > >> to check, or call inject:into: directly, with a proper initial value. > > > > I am sorry but I am getting really tired of this, you should read what > is being said. > do that change, I am not against it. Ben just asked for an example and I thought it would be helpful. > > > > I am not suggesting to stop using #anyOne because I like why it is there > and what it can do. > > > > The change I want is what happens with an empty collection when using > the simplest selector, #sum. > > > > I do not want to say to some collection of numbers #sumIfEmpty: [0], > because summing numbers starting from zero is the most common case and > everybody expects that, hence the unary selector fits. > > > > I want the less common cases to use the more complicated API, as in some > collection of colors #sumIfEmpty: [ Color black ] > > > > In my book that is common sense API design. > > > > Doing that I do no take anything away, because today you already have to > make sure the collection is not empty. > > > > The only change would be in the error behaviour. I think that is a > reasonable price to pay. Instead of having #anyOne fail, it will say that > #+ cannot add 0 to some object, and in a comment we can point to the > alternative API. > > > > > http://izquotes.com/quote/242740 right ? > > > >> cheers -ben > >> > >> > > >> >>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo < > [email protected]> wrote: > >> >>> > >> >>> I don't want to be heretic (or too orthodox), but why not to > delegate > >> >>> this behavior to other class (an iterator maybe?). > >> >>> > >> >>> It's too tempting adding these convenience methods to Collection > >> >>> and/or subclasses, but anything that requires an explicit protocol > of > >> >>> its elements is wrong, IMO. > >> >>> > >> >>> something like aCollection arithmetic sum: [...] or.... aCollection > >> >>> arithmetic avg. > >> >> > >> >> > >> >> Interesting thought! > >> > > >> > +100 > >> > > >> > Doru > >> > > >> >>> > >> >>> My two cents for this. > >> >>> > >> >>> Regards! > >> >>> > >> >>> > >> >>> Esteban A. Maringolo > >> >>> > >> >> > >> >> > >> > > >> > -- > >> > www.tudorgirba.com > >> > > >> > "Every thing has its own flow." > >> > > >> > > >> > > >> > > >> > > > > > > >
