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

Luciano Notarfrancesco luchiano at gmail.com
Tue Feb 6 09:30:05 PST 2024


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).

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.

Just wanted to add something to the discussion…
Cheers,
Luciano


On Wed, Feb 7, 2024 at 00:23 Gerald Klix via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

>
> 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: https://github.com/dbanay/Smalltalk)
> >>
> >> 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
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240207/63285241/attachment-0001.htm>


More information about the Cuis-dev mailing list