2015-12-22 3:46 GMT+01:00 Ben Coman <btc@openinworld.com>:

On Wed, Dec 2, 2015 at 3:38 AM, Tudor Girba <tudor@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 <btc@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...

��

On Sat, Dec 5, 2015 at 3:12 AM, Max Leske <maxleske@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 <sven@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