[Cuis-dev] [DEFECT] #copyFrom:count: for OrderedCollections
Nicolas Cellier
nicolas.cellier.aka.nice at gmail.com
Tue Feb 6 08:37:56 PST 2024
Hi Juan,
Le mar. 6 févr. 2024 à 17:22, Juan Vuletich via Cuis-dev
<cuis-dev at lists.cuis.st> a écrit :
>
> 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.
>
IMO, better fix the comment than the behavior.
The purpose of new: has always been to allocate enough room for
storing n elements.
For fixed size (Arrayed) collections, the answer is a collection
initialized with Undefined object(s).
Or whatever is the default element for non-pointer kind (ByteArray,
String, ...).
So it effectively has a size n, but the contents is somehow
un-initialized, only the container is.
For OrderedCollection, we don't have to initialize any contents at
all, because that will be so much easier by explicitly adding.
And for Set and Dictionary, we would have to initialize the contents
with n different arbitrary objects, which would be absolutely
nonsensical.
So, IMO, the expectation (SomeCollectionClass new: n) size = n is
plain wrong, that's not the intent of new:.
It's just true for fixed size collections, because, well, they have a
fixed size...
Of course, you can change that, but now you'll need another message to
express the intention to allocate enough room for n elements.
And if you do that, you'll just re-invent new: with another name.
I don't understand why you would do that, except for creating
cross-dialect nightmares.
Nicolas
> 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,
>
> --
> Juan Vuletich
> cuis.st
> github.com/jvuletich
> researchgate.net/profile/Juan-Vuletich
> independent.academia.edu/JuanVuletich
> patents.justia.com/inventor/juan-manuel-vuletich
> linkedin.com/in/juan-vuletich-75611b3
> twitter.com/JuanVuletich
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
More information about the Cuis-dev
mailing list