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

Luciano Notarfrancesco luchiano at gmail.com
Tue Feb 6 11:00:10 PST 2024


I would say not the class but the receiver is the only one with the full
context, as illustrated by Text>>grownTo: (and other examples in my code)

On Wed, Feb 7, 2024 at 01:57 Andres Valloud via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> 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,
> >
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240207/b8865a55/attachment.htm>


More information about the Cuis-dev mailing list