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

[Luciano Notarfrancesco]

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?

On Wed, Feb 7, 2024 at 00:30 Luciano Notarfrancesco <luchiano at gmail.com>
wrote:

> 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/53c9dde5/attachment.htm>