> On 22 Dec 2015, at 10:22, Nicolas Cellier
> <nicolas.cellier.aka.n...@gmail.com> wrote:
>
>
>
> 2015-12-22 3:46 GMT+01:00 Ben Coman <b...@openinworld.com>:
> On Wed, Dec 2, 2015 at 3:38 AM, Tudor Girba <tu...@tudorgirba.com> wrote:
> > 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.
>
> This seems the crux of the disparate viewpoints, which is why I
> suggested return a *generic* Zero object as follows...
>
> > On 04 Dec 2015, at 01:49, Ben Coman <b...@openinworld.com> wrote:
> > do something like...
> >
> > Collection>>sum
> > | sum sample |
> > self isEmpty ifTrue: [ ^ ArithmeticZero ].
> > sample := self anyOne.
> > sum := self inject: sample into: [ :accum :each | accum + each ].
> > ^ sum - sample
>
>
> Nice, but generic zero can't work: you sometimes need to decide if it is the
> zero of vector space, or of associated field.
> The generic zero can't behave as both say a matrix and a scalar...
Indeed, that is what I said the first time Ben proposed this.
But I am curious, Nicolas, what you think of this, with your math
background/interest ?
> On Sat, Dec 5, 2015 at 3:12 AM, Max Leske <maxle...@gmail.com> wrote:
> > While I think you might be on to something, I think we should take small
> > steps. I’d be happy already if we can just get rid of one superfluous method
> > and provide a better API without starting to think about the deeper
> > semantics.
>
> Sure, small steps are better, except when this hits a sticking point
> that the bigger step may overcome. I think returning a generic zero
> allowing the program to proceed is better than throwing an generic
> error that the programmer needs to explicitly deal with. The concept
> of zero is well defined for the common arithmetic functions. Just for
> a thought experiment, what arithmetic functions would need to be dealt
> with.
>
> > ArithmeticZero class >> + anObject
> > ^anObject
>
> AritmeticZero class >> * anObject
> ^ anObject zero
>
> AritmeticZero class >> - anObject
> ^ anObject zero - anObject
>
>
> > Also, I think there’s a reason why Aconcagua is an external package:
> > developers usually are happy to work with numbers (which are already objects
> > in Smalltalk anyway) and they’re fast.
>
> Sure its an external package, but when you have a collection of weight
> readings for example, you want to use the internal convenient #sum
> method...
> { 4 kg . 5 kg . 6 kg } sum --> 16kg
> { } sum + 1 kg --> 1kg
> { } sum * 1 kg --> 0 kg^2 "hmmm, zero with units and
> multiplication starts getting more complicated - maybe should be left
> out of this discussion"
>
> > While #sumNumbers may *technically* be the best name (which
> > we can’t seem to agree on…), #sum, #sum: and #sum:ifEmpty:
> > form a triple that naturally fits into the naming protocol applied
> > elsewhere.
>
> So maybe alternative naming of the generic zero...
> #sum (empty --> EmptyAggregateZero)
> #sum: (empty --> EmptyAggregateZero)
> #sum: ifEmpty: (empty --> whatever)
>
>
> > On Mon, Dec 21, 2015 at 12:43 AM, Sven Van Caekenberghe <s...@stfx.eu>
> > wrote:
> > Doru,
> >
> > For me this whole discussion started because you (the standpoint that you
> > take) hijacked the best selector (#sum) for a use case that is much less
> > common than adding a collection of numbers which should give 0 when empty
> > (you hijack it by not wanting to return 0, which I totally understand, but
> > doing so you redefine the meaning/semantics).
> >
> > Max's point is to make everything more consistent and remove some API. I
> > support that too.
> >
> > Now, I like Max's proposal.
> >
> > But, you know, my conclusion when the thread ended was that it might be
> > better to throw all these selectors away, since #inject:into: covers most
> > use cases at least as well and at least as clear.
>
> #sum is very convenient and that lowers the barrier of entry for
> newcomers over the relatively exotic #inject:into: We should keep
> trying to work through the sticky points, but maybe you guys getting
> together IRL is better than continuing on the mail list.
>
> cheers -ben
