Hi Chris,<br>
<br>
I understand your caution against sending even more new messages to the inspectee. However, given my previous message in this post, would you withdraw your objection for this particular patch? We are already sending #size to inspected object while creating the field list (and by the way, #at:, too). :-)<br>
<br>
Talking about inspecting proxies more in general:<br>
<br>
> Inspectors are really "developer" level tools, and not application level tools.<br>
<br>
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? :)<br>
<br>
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.<br>
<br>
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.<br>
<br>
Best,<br>
Christoph<br>
<br>
<font color="#808080">---<br>
</font><font color="#808080"><i>Sent from </i></font><font color="#808080"><i><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><u><font color="#808080">Squeak Inbox Talk</font></u></a></i></font><br>
<br>
On 2022-01-13T23:40:39-06:00, asqueaker@gmail.com wrote:<br>
<br>
> Hi Christoph, hi Marcel,<br>
> <br>
> > > I would say that #size being an expensive operation on a collection is quite surprising and thus not foreseeable in general.<br>
> ><br>
> ><br>
> > +1<br>
> <br>
> It's not that it's expensive, it's that it requires a (quick) trip<br>
> through the db stack which involves hitting a necessary Mutex critical<br>
> section which is often already occupied by a suspended debugger inside<br>
> an Application-level commit block.<br>
> <br>
> And so it complicates debugging because simply trying to use the dev<br>
> tools (e.g., inspecting an object) in that scenario, the image hangs<br>
> because of the Mutex, because of the #size being sent even though I<br>
> didn't need it sent.  That's why I'm already careful not to open<br>
> Explorers when I know I'm debugging in that scenario.  It would be<br>
> nice to not be pushed all the way to having to use basic inspectors<br>
> for *everything* on the off-chance that one of them *may* involve a<br>
> Proxy hit (e.g., no tra).<br>
> <br>
> > 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<br>
> > that normal inspector for such proxies should also be a MorphInspector. And so on.<br>
> <br>
> I appreciate the elegance of the abstraction delineation of<br>
> responsibilities you suggest for basic vs normal Inspectors.  But I do<br>
> think many systems that do Proxy reification could easily face a<br>
> situation similar to the above.<br>
> <br>
> Inspectors are really "developer" level tools, and not application<br>
> level tools.  I think this is a case where it's advantageous to<br>
> optimize the developers' experience.  I like Marcel's suggestion of<br>
> putting it as a field that sends #size to the receiver that can be<br>
> voluntarily clicked or avoided, if necessary for debugging.<br>
> <br>
> > Chris, you could override #inspectorClass on your MagmaCollection and have it answer MagmaCollectionInspector, a subclass of CollectionInspector which overrides #labelString again. :-)<br>
> <br>
> A good last-resort idea, thanks.  :)<br>
> <br>
> Best,<br>
>   Chris<br>
> <br>
>