[Cuis-dev] [DEFECT] #copyFrom:count: for OrderedCollections

[Andres Valloud]

Be careful with that "false polymorphism" argument.  Going down that 
route means you can ignore the receiver's class when you see a selector 
because a selector can only have one meaning.  In a sense, it promotes 
selectors to operators.

It should be pretty clear that collections like Array and Set should 
behave differently.  Why is that being ignored?

Consider this alternate interpretation.  The root cause of this problem 
seems to be that some code has the expectation that

	species new: n

can have exactly one meaning.  The sender is ignoring the receiver 
class.  Only the receiver class has that context.  So the receiver class 
should be given the task of creating the new instance instead --- this 
is why arithmetic has double dispatching, for example.

Andres.

On 2/6/24 8:21 AM, Juan Vuletich via Cuis-dev wrote:
> Let me also elaborate a bit on the rationale.
> 
> In Smalltalk-80 (and every other Smalltalk system since then), the docs 
> will say that #new: will answer a collection of the requested size. But 
> it is not like that for Set, Dictionary, OrderedCollection and a few 
> others, that give a completely different semantics to this message. It 
> is no _that_ bad when the message is sent to an explicit class, although 
> you need to be aware of this.
> 
> The real problem is when someone does `someCollection species new: 
> aNumber`. It gets really tricky to find out what is going to happen.
> 
> This is a prime example of what I call "False Polymorphism". It looks 
> like a polymorphic message, but it is not. It is (at least) two sets of 
> senders/implementors, completely separated. This means obscure, 
> misleading code. It makes me sick. I fix every instance of this I see. 
> It rarely happens in the base Smalltalk-80 classes, but it is still wrong.
> 
> Thanks,
>