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

No it shouldn't. If the compiler throws an error it will be thrown while 
you're halfways through recompiling the class hierarchy and will end up 
with an inconsistent system (and likely no way out). If you want to fix 
this problem you should deal with it when you remove the iVar (e.g., the 
browser should check if there are still references and put up a message 
set so you can fix them).

Also, keep in mind you can get to those vars by inspecting Undeclared 
and using "references to..." you can find where they are being used.

Cheers,
   - Andreas