<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"> </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"> </div><div dir="auto">Just wanted to add something to the discussion…</div><div dir="auto">Cheers,</div><div dir="auto">Luciano</div> </div><div> <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">cuis-dev@lists.cuis.st</a>> wrote: </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)"> On 2/6/24 5:07 PM, Juan Vuletich via Cuis-dev wrote: > On 2/6/2024 12:44 PM, Gerald Klix via Cuis-dev wrote: >> OMG, what have I done! >> >> PLEASE DON'T!!!!!!!!!!!!! >> >> See below. >> >> >> On 2/6/24 3:56 PM, Juan Vuletich via Cuis-dev wrote: >>> On 2/1/2024 5:43 PM, Gerald Klix via Cuis-dev wrote: >>>> Hi all, Hi Juan, >>>> >>>> I found a glitch in #copyFrom:count. >>>> IHMO both expression should work: >>>> >>>> --- snip --- >>>> 1 to: 10 :: copyFrom: 1 count: 3. >>>> >>>> 1 to: 10 :: asOrderedCollection copyFrom: 1 count: 3. >>>> --- snap --- >>>> >>>> The later creates an empty OrderedCollection and fails. >>>> >>>> I attached a change set, that replaces sends of #new: with >>>> sends of #sizeOf: in various methods, >>>> although some of these methods are special cased >>>> in OrderedCollection. >>>> >>>> >>>> Best Regards, >>>> >>>> Gerald >>> >>> Thanks Gerald. I integrated this a few days ago. Still, I think that >>> >>> | n | >>> n := whatever number. >>> (AnyCollectionClass new: n) size = n >>> >>> should _always_ evaluate to true (or fail if it doesn't make sense). >>> So I pushed some very substantial changes that kept me quite busy >>> for several days. Now `OrderedCollection new: 10` will fail. Same >>> for Set, Dictionary, Bag and a few others. I've adjusted many >>> packages accordingly. >>> >>> Cheers, >>> >> Oh my goodness, that breaks so much of my and everyone else's code. >> Please don't!!!!! >> >> This behavior was already present in Smalltalk/V for MSDos >> and in Smalltalk-80 (see: <a href="https://github.com/dbanay/Smalltalk" rel="noreferrer" target="_blank">https://github.com/dbanay/Smalltalk</a>) >> >> Please note, 40 year ago my computer science education >> began more or less with Algebraic Specification: >> I am acutely aware of this inconsistency! >> >> Everyone – even language lawyers – can like with this invariant: >> (AnyCollectionClass sizeOf: n) size = n >> >> Please follow my advice! >> >> >> Best Regards, >> >> Gerald > > :D > > I know it was like that in Smalltalk-80. That's why I made it give an > error, and not just answer `OrderedCollection ofSize: n` that would be > the correct answer! > > It is trivial to define: > > new: n > ^self new > > in Collection, or OrderedCollection or anywhere you need it. Or fix > the code, and just call `OrderedCollection new`. Current systems can > handle some GC stress without much drama... > > Besides, check the senders of #newWithRoomForMoreThan: . Don't they > start making sense now? > > Cheers, > Juan, consistency-wise, this all makes sense! In an implementation that is used for real work, you should not changes semantics so lightheartedly. If you really want to do this you should proceed it like this: For current Cuis 6.3 you should mark these methods, as "to be deprecated" (by some means yet to be invented). For Cuis 6.4 you could mark them as deprecated and write messages to the transcript or bother the user/programmer with a (Pre)-Debugger. For Cuis 6.5 or later you may enforce that semantics. Of course there still will be hue and cry, but people had their time to adapt and after a lot of complaining, event I would have found a way to live with it :) Now I am in the middle of an important project (money-wise) and I have to deal with that – ah, äm, well – shit! I hope you understand, Gerald -- Cuis-dev mailing list <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> </blockquote></div></div>