[squeak-dev] The Inbox: Tools-ct.1101.mcz

Chris Muller asqueaker at gmail.com
Fri Jan 14 05:40:39 UTC 2022

Hi Christoph, hi Marcel,

> > I would say that #size being an expensive operation on a collection is quite surprising and thus not foreseeable in general.
> +1

It's not that it's expensive, it's that it requires a (quick) trip
through the db stack which involves hitting a necessary Mutex critical
section which is often already occupied by a suspended debugger inside
an Application-level commit block.

And so it complicates debugging because simply trying to use the dev
tools (e.g., inspecting an object) in that scenario, the image hangs
because of the Mutex, because of the #size being sent even though I
didn't need it sent.  That's why I'm already careful not to open
Explorers when I know I'm debugging in that scenario.  It would be
nice to not be pushed all the way to having to use basic inspectors
for *everything* on the off-chance that one of them *may* involve a
Proxy hit (e.g., no tra).

> Currently the default Inspector should not be used to look behind proxies. That's what the BasicInspector is for. If a proxy mimics morphs, than
> that normal inspector for such proxies should also be a MorphInspector. And so on.

I appreciate the elegance of the abstraction delineation of
responsibilities you suggest for basic vs normal Inspectors.  But I do
think many systems that do Proxy reification could easily face a
situation similar to the above.

Inspectors are really "developer" level tools, and not application
level tools.  I think this is a case where it's advantageous to
optimize the developers' experience.  I like Marcel's suggestion of
putting it as a field that sends #size to the receiver that can be
voluntarily clicked or avoided, if necessary for debugging.

> Chris, you could override #inspectorClass on your MagmaCollection and have it answer MagmaCollectionInspector, a subclass of CollectionInspector which overrides #labelString again. :-)

A good last-resort idea, thanks.  :)


More information about the Squeak-dev mailing list