Hi,
Yes, I do not like it… I think it is there so that you can just make a variable
subclass and at: / at:put: will work without
having to re-implement them…
Marcus
> On 12 Mar 2019, at 04:55, Richard O'Keefe <[email protected]> wrote:
>
> I understand #basicAt:[put:] being in Object, but I never understood
> #at:[put:] being there.
> GNU Smalltalk:
> st> nil at: 1
> Object: nil error: Invalid value nil: object not indexable
> In my Smalltalk, you get a DNU.
> In Squeak you get a debugger window with title
> Error: instances of UndefinedObject are not indexable
> The same for Boolean, Character, and Integer,
> except Squeak where (20 factorial at: 1) answers 0 (oh dear oh dear oh dear).
> In VW you get a "Subscript out of bounds" error, which is disappointing,
> as do true and $a, but a LargePositiveinteger gets #shouldNotImplement.
>
>
> On Tue, 12 Mar 2019 at 15:28, Tim Mackinnon <[email protected]> wrote:
> If you forget to initialise a variable which you thought was a Dictionary -
> you get a confusing error message: "Error: only integers should be used as
> indices” if you try an at:put:
>
> This is a consequence of having at:put: defined on Object (which is a bit
> nasty)
>
> Should UndefinedObject at least override this and signal something a bit more
> obvious? This is a common and easily done thing and we don't support it very
> well.
>
> I just did it in some code, and was scratching my head initially until I read
> the stack properly and realised it was something much simpler than I thought
> I had done.
>
> Any thoughts on this?