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