On Tue, 27 Dec 2016, Tobias Pape wrote:

>
> On 27.12.2016, at 17:45, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>
>> On Tue, 27 Dec 2016, Tobias Pape wrote:
>> 
>>> 
>>> On 25.12.2016, at 17:09, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>>> 
>>>> Hi All,
>>>> We had a discussion[1] about #species, in the context of Sets and IdentitySets, and its multiple roles which it cannot fulfill[2].
>>>> A similar issue arises in case of OrderedCollection and its subclasses, but with a smoother resolution, because an OrderedCollection is always an acceptable result (for #collect:).
>>>> So, I suggest we should change OrderedCollection >> #collect: to always return an OrderedCollection. This change obviously would not affect OrderedCollection, but we already have the same override in SortedCollection.
>>>> Example:
>>>> Currently the following raises and error:
>>>>
>>>> 	(FloatCollection withAll: #(1 2 3)) collect: #asString
>>>> Of course, #collect:as: works as expected:
>>>>
>>>> 	(FloatCollection withAll: #(1 2 3)) collect: #asString as: OrderedCollection
>>>> 	"==> an OrderedCollection('1.0' '2.0' '3.0')"
>>>> So, why not make #collect: behave the same way?
>>>> This change would make #species not being used in #collect:, which is similar to the solution we have in Set and subclasses.
>>>> Currently #select: and #copyEmpty also use #species, but no class implements #species in the hierarchy. So, changing #species to return OrderedCollection would have unwanted side effects. (This also shows that #species doesn't solve anything here.)
>>>> Any objections?
>>> 
>>> Just a question for clarification, would
>>>
>>> 	(FloatCollection withAll: #(1.0 2.0 3.0)) collect: [:ea | ea sqrt]
>>> 
>>> result in a FloatCollection or in an OrderedCollection?
>> 
>> An OrderedCollection of course. #collect: would always return an OrderedCollection.
>
> Ok, so to make good use of FloatCollections in the first place i would have to always use 
> collect:as: to _stay within_ the class? I somehow do not like that :(. I'd rather have to stay

So you'd rather have the errors?

> as much as possible with the closure property for large parts of the collection API.

What's the "closure property"?

>
> Whats wrong with species -> class, and collect: staying within the class?

Did you try the example in my first post?

species -> class would do nothing, because, as I mentioned in my original 
post, species is not overridden anywhere in the class hierarchy.

> We got several specialized collections, I don't want a buch of collectFloat: collectInteger: collectShortPoint: 
> for each and every class.

Why would such methods ever appear? Have you seen anything like that 
anywere?

Levente

>
>
> Best regards
> 	-Tobas
>
>
>
>> 
>> Levente
>> 
>>> 
>>> Best regards
>>> 	-Tobias
>>> 
>>>> Levente
>>>> [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-November/180766.html
>>>> [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-November/180809.html