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

[Gerald Klix]

I strongly agree!

As I said, I am aware of the inconsistencies and the false polymorphism.
For my private projects I really need language that gets work done
and not a language that sets out to prove a point.

In general: Backward compatibility is much more important than consistency.
Especially with a language where is the code is the only documentation.

If you look at the Pharo catalog, there are many projects that are not
marked as compatible with the latest Pharo release; I strongly
suspect this is for reasons or lack of compatibility.

Let's imagine a hypothetical situation.
A customer takes the existing Cuis 6.2 inline documentation
and behavior seriously and used OrderedCollection>>#new: as
described and used/demoed in the image. When Cuis 6.4 will become
the new rolling release version and Cuis 6.3 will be the new stable release,
your customer may have to change
their code; probably a lot of it.
I bet, they will be already busy with more urgent problems.

I am glad I just missed the Cuis 6.2 frozen version,
I would have been tempted to use it for Haver.
If I had done so,
all the accumulated incompatibilities will hit me
at the very same time.


(Not) just my 3.00€,

Gerald



On 2/6/24 5:37 PM, Nicolas Cellier via Cuis-dev wrote:
> 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