[Cuis-dev] [DEFECT] #copyFrom:count: for OrderedCollections
Andres Valloud
ten at smallinteger.com
Tue Feb 6 13:59:25 PST 2024
Even if new: was polymorphic for Array and OrderedCollection, you still
can't send add: to Array. So, are (instances of) these classes really
"polymorphic"?... those "semantics from the sender's perspective" change
on e.g. whether the sender sends add:. It's tricky and requires care.
Polymorphism makes more sense from the side of the sender, and even then
only taking into account exactly what the sender is doing. If the
intent depends on the receivers in ways that are not compatible, that's
asking for double dispatching or something of that nature.
Just be careful what you wish for. That is looks like polymorphism
doesn't mean it actually is, false or otherwise. As a concrete example,
simply because you see the message new: doesn't mean that the message
itself is wrong if it provides different implementations. It could just
be that the sender is wrong in asking the same behavior from Array and
OrderedCollection, regardless of whether new: or sizeOf: or whatever
else is sent.
On 2/6/24 11:53 AM, Hernán Wilkinson via Cuis-dev wrote:
> The definition of polymorphism, sadly, is not clear... Each
> language/book/culture defines it differently and uses that word
> differently and sometimes in contradictory ways.
> The definition I like to use after many years of teaching the subject
> is: "Objects of a set are polymorphic among themselves with respect to a
> set of messages, if the objects of the first set respond semantically
> the same to the messages of the second".
> "Semantically the same" means "they do the same thing", no matter how
> they do it (it implies that parameters must be polymorphic and that the
> results are polymorphic)
>
> If #new: n sent to Array creates a collection of n elements but sent to
> OrderedCollection does not, then Array and OrderedCollection are not
> polymorphic with respect to #new:, and therefore you cannot replace one
> receiver with another.
>
> A clear example of Array and OrderedCollection not being polymorphic
> regarding #new: is:
> (Array new: 10) at: 5 --> returns nil.
> (OrderedCollection new: 10) at: 5 --> gives error
>
> This behavior does not follow the "minimum attonishment" principle and
> therefore it is good to avoid it.
>
> It is true that it generates compatibility issues, but I also think that
> sometimes we should break that compatibility if we believe that what we
> are doing is better, I do not want Smalltalk neither Cuis to be what
> Alan Kay said a long time ago: "Once it got into production, it stops
> evolving due to the compatibility issues" (or something like that).
> It is also true that breaking compatibility should be done with care,
> and that is why this has been done on the rolling version (6.3), not the
> stable one (6.2). If we do not want compatibility issues we should work
> on the stable release and migrate to a different stable version if we
> want it/need it.
>
> When Juan told me about this problem the first thing we talked about was
> about the compatibility problems it could generate, but the idea of
> doing something better won over the compatibility idea... We are working
> on the rolling release and if the change generates more problems than
> solutions, we can go back to how it was.
>
> Let's give it a try and see what happens!
>
> Cheers!
> Hernan.
>
> On Tue, Feb 6, 2024 at 4:00 PM Luciano Notarfrancesco via Cuis-dev
> <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
>
> 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 <mailto: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 <mailto:Cuis-dev at lists.cuis.st>
> https://lists.cuis.st/mailman/listinfo/cuis-dev
> <https://lists.cuis.st/mailman/listinfo/cuis-dev>
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
> https://lists.cuis.st/mailman/listinfo/cuis-dev
> <https://lists.cuis.st/mailman/listinfo/cuis-dev>
>
>
>
> --
> *Hernán Wilkinson
> Agile Software Development, Teaching & Coaching*
> *Phone: +54-011*-4893-2057
> *Twitter: @HernanWilkinson*
> *site: http://www.10Pines.com <http://www.10pines.com/>*
> Address: Alem 896, Floor 6, Buenos Aires, Argentina
>
More information about the Cuis-dev
mailing list