> I have the impression that they fit naturally in a mathematical
> package/libraries.
>
> Stef

You are right, in VW this is an extension that i proposed to integrate in the
NumericCollections package.

But the core of VW-NumericCollections is in the Squeak base image (you can do
arithmetics on collections like adding a number to it...). So this is why I
was proposing you integrate it.

cumulativeProduct and cumulativeSum really sound mathematical package
specific.

But in my opinion, the others (sumOf: maxOf: count: ...) are some very
 general purpose messages.
You can find such in matlab, F95, ...
They might be used anywhere you have math in squeak (squeak has a lot of math
especially but not only a lot of geometry).

I browsed the senders of #inject:into: just to check how it was used:
- it is used for concatenating strings or other collections with variants #,
#nextPutAll: #addAll: (the original posting on this thread)
- it is used in place of anySatisy: (inject:false into: ...need refactoring
 ?) - it is used to sum things (my proposition sumOf:)
- it is used to get max or min (my proposition maxOf:)
- it is used to count things (my proposition count:)
- in very rare case it does some other thing (packing string...)

Example:
DependentsArray>>size
 ^self inject: 0 into: [ :count :dep | dep ifNotNil: [ count _ count + 1 ]]

would be
 ^self count: [:each | each notNil]

I take a more academic example, because i do not really understand this one
above (overwriting a block temporary ? and what ifNil ? either it is broken
or i will learn something...)

addOtherMorphsTo: aMorph
 ...
 variableCount _ heights
      inject: 0
      into: [:count :ea | ea = 0 ifTrue: [count + 1] ifFalse: [count]].

would be:
 variableCount _ heights count: [:each | each = 0].

Which code is clearer, which one do you prefer ?
Today, inject:into: is obvious to me, but in my beginning Smalltalk days i
 can remember it was not. And i still prefer the second form for clarity. It
 is much more expressive.

Give a try to these messages and see how they spread into code, and how well
you would refactor those inject:into: and surely a lot of open-coded do
loops...

If you think they are useless simply because inject:into: exist,
then Collections are plenty of messages that are useless:
 reject: is select: [:e | (...) not]
 anySatisy: is contains:
 allSatisfy: is (contains: [:e | (..) not]) not
(that is really how i would have programmed things before implementing my
first proto #all:).

However, if you prefer a separate package, maybe you are right, you are
responsible for managing the growth of the base image.
But in this case, i suggest you might better remove Complex or other things
that does not seem to be used at all (see senders of #i and class refs of
Complex).

Sorry for being so long, but some decisions must be argued

-------------------------------------------------------