<div dir="auto">Also do we really need to support any SequenceableCollection as contents of a WriteStream (even Intervals?) or we could restrict it to fixed-size collections? Should CharacterSequences and Text be ArrayedCollections instead of SequenceableCollection?</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 7, 2024 at 00:30 Luciano Notarfrancesco <<a href="mailto:luchiano@gmail.com">luchiano@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="auto">Fantastic thread. I’ve been strugling with this myself since a few days ago with the fix that used sizeOf: because it broke my code (no big deal, I expect this to happen sometimes).</div><div dir="auto"><br></div><div dir="auto"><div dir="auto">I did some experiments and I ended up defining the message copyEmpty: (perhaps copyBlank: would be better name, because in Smalltalk collections empty means size=0) on the instance side instead of ofSize: on the class side. The reason for this is that sometimes on the class side you dont have all the information necessary to make a new blank collection compatible with the receiver. For example see Text>>grownTo:, we shouldnt need that method. In my arrays for math i have thr same problem, i need to do it on the instance side.</div><div dir="auto"><br></div><div dir="auto">Just wanted to add something to the discussion…</div><div dir="auto">Cheers,</div><div dir="auto">Luciano</div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 7, 2024 at 00:23 Gerald Klix via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br>
On 2/6/24 5:07 PM, Juan Vuletich via Cuis-dev wrote:<br>
> On 2/6/2024 12:44 PM, Gerald Klix via Cuis-dev wrote:<br>
>> OMG, what have I done!<br>
>><br>
>> PLEASE DON'T!!!!!!!!!!!!!<br>
>><br>
>> See below.<br>
>><br>
>><br>
>> On 2/6/24 3:56 PM, Juan Vuletich via Cuis-dev wrote:<br>
>>> On 2/1/2024 5:43 PM, Gerald Klix via Cuis-dev wrote:<br>
>>>> Hi all, Hi Juan,<br>
>>>><br>
>>>> I found a glitch in #copyFrom:count.<br>
>>>> IHMO both expression should work:<br>
>>>><br>
>>>> --- snip ---<br>
>>>> 1 to: 10 :: copyFrom: 1 count: 3.<br>
>>>><br>
>>>> 1 to: 10 :: asOrderedCollection copyFrom: 1 count: 3.<br>
>>>> --- snap ---<br>
>>>><br>
>>>> The later creates an empty OrderedCollection and fails.<br>
>>>><br>
>>>> I attached a change set, that replaces sends of #new: with<br>
>>>> sends of #sizeOf: in various methods,<br>
>>>> although some of these methods are special cased<br>
>>>> in OrderedCollection.<br>
>>>><br>
>>>><br>
>>>> Best Regards,<br>
>>>><br>
>>>> Gerald<br>
>>><br>
>>> Thanks Gerald. I integrated this a few days ago. Still, I think that<br>
>>><br>
>>> | n |<br>
>>> n := whatever number.<br>
>>> (AnyCollectionClass new: n) size = n<br>
>>><br>
>>> should _always_ evaluate to true (or fail if it doesn't make sense). <br>
>>> So I pushed some very substantial changes that kept me quite busy <br>
>>> for several days. Now `OrderedCollection new: 10` will fail. Same <br>
>>> for Set, Dictionary, Bag and a few others. I've adjusted many <br>
>>> packages accordingly.<br>
>>><br>
>>> Cheers,<br>
>>><br>
>> Oh my goodness, that breaks so much of my and everyone else's code.<br>
>> Please don't!!!!!<br>
>><br>
>> This behavior was already present in Smalltalk/V for MSDos<br>
>> and in Smalltalk-80 (see: <a href="https://github.com/dbanay/Smalltalk" rel="noreferrer" target="_blank">https://github.com/dbanay/Smalltalk</a>)<br>
>><br>
>> Please note, 40 year ago my computer science education<br>
>> began more or less with Algebraic Specification:<br>
>> I am acutely aware of this inconsistency!<br>
>><br>
>> Everyone – even language lawyers – can like with this invariant:<br>
>> (AnyCollectionClass sizeOf: n) size = n<br>
>><br>
>> Please follow my advice!<br>
>><br>
>><br>
>> Best Regards,<br>
>><br>
>> Gerald<br>
><br>
> :D<br>
><br>
> I know it was like that in Smalltalk-80. That's why I made it give an <br>
> error, and not just answer `OrderedCollection ofSize: n` that would be <br>
> the correct answer!<br>
><br>
> It is trivial to define:<br>
><br>
> new: n<br>
>     ^self new<br>
><br>
> in Collection, or OrderedCollection or anywhere you need it. Or fix <br>
> the code, and just call `OrderedCollection new`. Current systems can <br>
> handle some GC stress without much drama...<br>
><br>
> Besides, check the senders of #newWithRoomForMoreThan: . Don't they <br>
> start making sense now?<br>
><br>
> Cheers,<br>
><br>
Juan,<br>
<br>
consistency-wise, this all makes sense!<br>
<br>
In an implementation that is used for real work,<br>
you should not changes semantics so lightheartedly.<br>
<br>
If you really want to do this you should proceed it like this:<br>
<br>
For current Cuis 6.3 you should mark these methods,<br>
as "to be deprecated" (by some means yet to be invented).<br>
<br>
For Cuis 6.4 you could mark them as deprecated<br>
and write messages to the transcript or bother the user/programmer<br>
with a (Pre)-Debugger.<br>
<br>
For Cuis 6.5 or later you may enforce that semantics.<br>
<br>
Of course there still will be hue and cry,<br>
but people had their time to adapt and<br>
after a lot of complaining, event I would have found<br>
a way to live with it :)<br>
<br>
Now I am in the middle of an important project (money-wise)<br>
and I have to deal with that – ah, äm, well – shit!<br>
<br>
<br>
I hope you understand,<br>
<br>
Gerald<br>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div></div>
</blockquote></div></div>