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
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
