Why does Squeak what it does when a method references a non-existing ivar?

Colin Putney cputney at wiresong.ca
Sat Nov 12 01:43:40 UTC 2005

On Nov 11, 2005, at 7:43 PM, Cees De Groot wrote:

> I had a funny problem with Seaside where a child component behaved in
> a funny way, which turned out to be caused by the ivar representing
> the child component not being present in the class.
> On investigation, it turns out that when the class is recompiled,
> methods that had e.g. a storeIntoRcvr: opcode to write the now-absent
> ivar get recompiled with a storeIntoLit: opcode.
> Shouldn't the compiler throw an error instead? This can result in very
> hard-to-track bugs...

Well, that would mean that you could never remove an ivar that was  
still referenced by a method. There's a certain security in that, I  
suppose, but personally, I'd rather the system didn't protect me from  
myself. The binding in the literal frame is also referenced by  
Undeclared, which makes it easier to find.


More information about the Squeak-dev mailing list