nil should not uderstand at:

[pavel-krivanek]

Bug description If we evaluate a message like nil at: 'aString', it, instead of MessageNotUnderstood, raises Error: only integers should be used as indices because it tries to call the primitive, which is more confusing than it should be. Maybe some other Object primitives should be checked as well.

[guillep]

I kind of agree with this. It also happens with other objects where #at: makes no sense.

at: is up in the hierarchy just as a convenience. Like that, people implementing new [byte/word]array subclasses do not need to define #at:.

There is the same problem with #size, #basicAt:.

This also bothers me when doing TDD

[tesonep]

It is ugly we should fix it, also they pollute Object a lot. Maybe we can add a trait or a superclass having them or for classes in the core to add the implementation in the variable classes. There are only 48 variable classes. From them:

• 20 are extending Object so we can add VariableObject in that case.
• 18 are collections and can be handled differently
• 10 are strange cases that should be seen one by one.

On Mon, Jun 26, 2023 at 9:04 AM Guille Polito @.***> wrote:

I kind of agree with this. It also happens with other objects where #at: makes no sense.

at: is up in the hierarchy just as a convenience. Like that, people

implementing new [byte/word]array subclasses do not need to define #at:.

There is the same problem with #size, #basicAt:.

This also bothers me when doing TDD

— Reply to this email directly, view it on GitHub https://github.com/pharo-project/pharo/issues/14120#issuecomment-1606832915, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACWY7574NFOTNLEKCL2TUDXNEX7FANCNFSM6AAAAAAZTWICBQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Pablo Tesone. @.***

[Ducasse]

Yes cleaning this would be great. I wonder why at: is not at the minimum in Collection.