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

[Gerald Klix]

On 2/6/24 5:21 PM, Juan Vuletich 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.
_*NO!*_
Let me quote from my snarfed copy of the Bluebook/ Page 139
"The messages new and new: can be used to create instances of particular 
kinds of collections."

That's all that's said about #new:.

If you look at the Smalltalk80 comment for OrderedCollection>>#new: here 
it is:

Set>>#new: looks like this:



That's the comment for IdentityDictionary>>#new:

Nothing is said about the semantics of #new:, instead the comments mostly
deal with implementation details.
>
> The real problem is when someone does `someCollection species new: 
> aNumber`. It gets really tricky to find out what is going to happen.
This wasn't the case with Smalltalk-80, it had 8 implementors of #new:.
>
> 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.
The main issue is, that you are deeply convinced
that the postulate that
<someClass> new: <someSmallPositiveInteger> answers an object of size
someSmallPositiveInteger is true. This never was the case.
Your point about false polymorphism isn't a semantic one,
it's a purely pragmatic one. If I had to maintain Cuis, I would
love to have some simpler semantics for #new:, but also
I support backwards compatibility over several versions.

For Haver I will implement the following:

#new: will keep its – admittedly – confusing semantics.
#sizeOf: will create a SequenceableCollection of the right size
and signal an error for Sets and their sub classes.
If I need it, I will implement #forceSizeOf: for sets
and dictionaries that will create such a beast
with n arbitrary objects or arbitrary keys mapped to nil.

When I have the proper infrastructure for deprecation in place,
I will rethink adopting your changes to the semantics of #new:.

I will do this, despite the fact that I am the only user of Haver, that I
know about.


Best Regards,

Gerald



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240207/569f8429/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbnooojcpoopcnbl.png
Type: image/png
Size: 20882 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240207/569f8429/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: omjdmihmjgffmfec.png
Type: image/png
Size: 10369 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240207/569f8429/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: miboapnmkmalldbg.png
Type: image/png
Size: 18890 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240207/569f8429/attachment-0005.png>