[ANSI-Smalltalk] Behaviour of #collect:

[Richard O'Keefe]

On 23 Sep 2008, at 3:45 pm, Ralph Johnson wrote:

> If that is what it takes to make #collect: work the way you want, then
> I don't want it to work that way.  In my opinion, you are making the
> implementation very complicated for only a slight improvement in
> behavior.

I didn't say that was the best possible code,
it just happens to be the code I have.
What's missing is a method that would be nice
to have anyway.

     SomeCollectionClass canHoldAll: aCollection
        ^aCollection allSatisfy: [:each | "some test"]


Then
    Collection>>
      collect: aBlock
        ^self species withAll: self collect: aBlock
    SequencedReadableCollection>>
      collect: aBlock
         |a|
         a := Array withAll: self collect: aBlock.
         ^(self species canHoldAll: a)
           ifTrue:  [self species withAll: a]
           ifFalse: [a]
     ReadOnlyArray>>
       collect: aBlock
          ^self pvtCollect: aBlock
     SequencedContractibleCollection>>
       collect: aBlock
         ^OrderedCollection withAll: self collect: aBlock

I didn't feel like writing #canHoldAll: just for the sake of
#collect:.  I've wanted to use #canHoldAll: a couple of other
times, but worked around it.

>
> I would rather just say "aString asArray collect: [:each | each
> codePoint]" when I want #collect: to return an array.
>
Well, #asArray isn't standard.

But this misses the point that you might not KNOW that you need
#collect: to return something other than the receiver's type.
You might not KNOW that aString is in fact a string.
The use case to consider is

	aCollection collect: aBlock

where somebody else handed you aCollection and aBlock.

I find it difficult to believe that anyone ever *designed*
Smalltalk's collection classes so that
	'abc' collect: [:each | each codePoint]
would drop you into the debugger.  I suspect that the
possibility was simply overlooked, just as the possibility
of
	aCollection addAll: aCollection
and	aCollection removeAll: aCollection

appears to have been overlooked.

The simplicity that counts most is simplicity for Smalltalk  
*programmers*,
not Smalltalk *implementors*.


>