> Hm ... that's a fair point. Still, I am not sure how the perfect solution to this issue could look like - I can think of both situations where you would like to inspect the proxy's interna and situations where you are interested in the eventual public representation. Maybe our inspectors should "automatically" "detect" proxies and offer both views in this case? For instance, a simple detection heuristic could be "(thisContext objectClass: object) ~~ (object perform: #class)". If a proxy is detected, #inspect: could automatically fall back to the basic inspector, and maybe offer a "rich inspector" field or menu item. What do you think? :)

+1 for helping Squeak support the Proxy pattern again.

> Then again, what is the problem with always choosing "basic inspect" rather then "inspect" when you want to look into proxies? It is a pretty straightforward decision tree in my eyes.

Because of scenarios like the one I described.  When debugging an
application that utilizes Proxy's, and the IDE (Inspector) is sending
messages to the objects, it can complicate debugging in unexpected
ways like that.  The user didn't want to "look into proxies," just the
regular domain object, but because of the proxy reification machinery,
it hung up due to the debugger already being inside a Mutex critical
block also used by the Proxy reification.

Admittedly, it's a pretty obscure scenario, I'm able to interrupt
and press Resume to get the inspector, so not a huge deal.  IMO, it's
simply illustrative of the caution that should be heeded for tools to
send messages to domain objects willy-nilly.

> In any case, I would ask you to discuss the general issue of proxy support in inspectors separately from this inbox proposal. As argued above, to me it does not appear as a precedence case.

That's fine.  Squeak is already broken for using Proxy's much worse
than this, and I have a workaround, if necessary.  Go for it.