On Tue, Dec 2, 2014 at 1:20 AM, stepharo <stepharo@free.fr> wrote:
What is the old behavior?

These are from Smalltalk-80 v2 of April 1, 1983 on 31 May 1983 at 9:10:35 am

Object methods for private
species
"Answer the preferred class for reconstructing the receiver.�� For example,��
collections create new collections whenever enumeration messages such as��
collect: or select: are invoked.�� The new kind of collection is determined by��
the species of the original collection.�� Species and class are not always the��
same.�� For example, the species of Interval is Array."

^self class

Collection methods for enumerating
collect: aBlock��
"Evaluate aBlock with each of the receiver's elements as the argument.�� Collect the��
resulting values into a collection that is like the receiver.�� Answer the new��
collection. "

| newCollection |
newCollection _ self species new.
self do: [:each | newCollection add: (aBlock value: each)].
^newCollection

select: aBlock��
"Evaluate aBlock with each of the receiver's elements as the argument.��
Collect into a new collection like the receiver, only those elements for which
aBlock evaluates to true.�� Answer the new collection."

| newCollection |
newCollection _ self species new.
self do: [:each | (aBlock value: each) ifTrue: [newCollection add: each]].
^newCollection

Interval methods for private
species
^Array

But there are also already uses for comparing:

CharacterBlock methods for comparing
= aCharacterBlock��
self species = aCharacterBlock species
ifTrue: [^stringIndex = aCharacterBlock stringIndex]
ifFalse: [^false]

Interval methods for comparing
= anInterval��
"Answer true if my species and anInterval species are equal, and
if our starts, steps and sizes are equal."

self species == anInterval species
ifTrue: [^start = anInterval first
and: [step = anInterval increment and: [self size = anInterval size]]]
ifFalse: [^false]


However, the species comment clearly states the usage pattern, even though it fails to mention the intent (to provide a mutable container with which to derive a new collection from the original).
��
In addition it would be good to have tests for such core library.

+ 1

Stef

Le 1/12/14 11:44, Sven Van Caekenberghe a ��crit��:


Begin forwarded message:

From: Bert Freudenberg <bert@freudenbergs.de>
Subject: Re: [squeak-dev] IdentitySet>>collect:
Date: 1 Dec 2014 11:35:00 CET
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>

On 01.12.2014, at 07:35, Colin Putney <colin@wiresong.com> wrote:

On Sun, Nov 30, 2014 at 6:20 AM, Bert Freudenberg <bert@freudenbergs.de> wrote:
��
How would you define ���type��� here? Same class?

Yes, same class. It might be reasonable to answer instances of analogous classes for weak collections, and expect the caller to use #collect:as: if they want to retain weakness.��

Colin

That���s certainly simple:

�����collect: returns a collection of the same class as the receiver, except for weak collections, which answer non-weak equivalents. To return a collection of a different class, use collect:as:"

- Bert -

The above definition makes perfect sense to me. The default should be simple and predictable, the more complex and special cases can be handled by a more convoluted API.

And we should change callers that depend on the old behaviour.

Sven







--
best,
Eliot