On Tue, Dec 2, 2014 at 1:20 AM, stepharo <stepharo at free.fr> wrote:

>  What is the old behavior?
>

These are from Smalltalk-80 v2 of

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 at 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 at lists.squeakfoundation.org>
>  *Reply-To: *The general-purpose Squeak developers list <
> squeak-dev at lists.squeakfoundation.org>
>
>  On 01.12.2014, at 07:35, Colin Putney <colin at wiresong.com> wrote:
>
>
>  On Sun, Nov 30, 2014 at 6:20 AM, Bert Freudenberg <bert at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20141202/85daf4ee/attachment.htm