Hi all,

I'm enclosing an updated version of the tool fixing a minor issue; for some reason HierarchyBrowser >> #setClass: won't update the centralClass variable when you change the inspected object (i.e. when you save a new object in the self field). 

As a workaround I've simply overriden InspectorBrowser >> #update to force the update and opened an issue "Inconsistent HierarchyBrowser #setClass: behavior - a bug or a feature?" to address the root cause, possibly a bug?

There's a fundamental difference between an Inspector and a "verbose" tool like this: Inspectors are developer tools with well defined and expected behavior while the tool I propose is a combination of an Inspector and a Hierarchy Browser with hopefully some added value for learners and users exploring unfamiliar objects.

Thanks,

best, 
Jaromir
^[^    
  --
Sent from Squeak Inbox Talk

On 2021-12-26T18:57:41+01:00, mail at jaromir.net wrote:

> Hi Christoph,
> 
> thanks a lot for your prompt response!
> 
> > - First of all, I think Squeak/Smalltalk has a good tradition of many small windows (SDI - single document interface) with all the inspectors, explorer, message traces, Monticello windows, etc. 
> 
> I'm getting used to it and can appreciate the benefits for more experienced users - you visualize just the necessary bit of information you're after without the clutter of "big compound windows" while keeping the big picture in your mind; beginners on the other hand are just training this ability to see the whole picture, they are not sure what exactly they are looking for (or at) and, at least in my case, often just wander around and try to make some sense of it all :) In this case a compound window might help by linking things that belong together; I'm by no means advocating such an approach in general :)
> 
> > But suum cuique - the InspectorBrowser as a fusion of inspector + browser already exist, and I don't see any harm in improving/extending this tool. You are also making a very good point in providing a view to explore state and behavior of an object at the same time. You do not even need to restrict the target group of this tool to beginners - experts could benefit from a more efficient tooling as well. :-)
> 
> That'd be more than I'd hope for; I use it e.g. when exploring an object I'm not familiar with...
> 
> > * I recommend you try out Autocompletion [1] if you haven't yet. It should help you reach your goal "if you want to try sending messages to the inspected object you don't have to look for which messages the object responds to", too. :-) It uses some heuristics for guessing the type of the current expression and will suggest you selectors from the relevant object's class hierarchy.
> 
> I did try autocompletion; it's a powerful tool if you already have some understanding about the system; when I started though, I had no idea what most of the messages did and struggled to locate them in the hierarchy to find out. But again, this might be because I learned myself without a teacher who would guide me...
> 
> > - Similarly to the inspectors in the debugger, the separate code pane in the object inquirer is not strictly required. You can also evaluate/print expressions in the value pane against the same receiver. I think it would not be necessary to add the second pane in the object inquirer, do you see any benefit from it? Otherwise, we would have a chance to simplify the UI a little bit which is rather complex right the moment.
> 
> Yes, I've never realized...; the only disadvantage might be if you evaluate in the value pane and hit 'save' (which I very often do subconsciously). Also, a beginner wouldn't even know whether she can do that and what the consequnces could be; and, in addition, the system yells when you try to leave the pane without saving the changes :) But it's an interesting thought!
> 
> > - Third, why subclass from the InspectorBrowser rather than extending it? I would vote for integrating your changes right into the InspectorBrowser, and *maybe* renaming it to Inquirer. 
> 
> I did extend the InspectorBrowser class first but then refactored to a subclass not to insult anybody in case the tool is already being used as is. If not, it surely makes sense to just extend it...
> 
> > Maybe a few people are familiar with the old name. Maybe extending the "do-it" vocabulary (print it, inspect it, explore it) with another verb (inquire it) would add too much complexity to the domaining, but not sure about this. Alternatively, we could at least make the refurbished InspectorBrowser available from the inspector/explorer menu. 
> 
> Yes indeed; I just wanted to present the idea but anything that would bring this tool to potential users would be great!
> 
> > Maybe we could even build a preference that automatically opens an InspectorBrowser for "inspect it" rather than a simple inspector.
> 
> I'm not sure about this because I personally use both - Inspector for a quick look and Inquirer for exploring unfamiliar objects; and Explorer too because it provides a nice access to senders hierarchy etc. :)
> 
> Thanks again for your thoughts!
> Best,
> 
> ~~~
> ^[^    Jaromir
> 
> Sent from Squeak Inbox Talk
> 
> On 2021-12-26T16:24:38+01:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:
> 
> > Hi Jaromir,
> > 
> > thank you for this contribution, looks like a nice idea! :-)
> > 
> > For now, here are just a few spontaneous thoughts:
> > 
> > - First of all, I think Squeak/Smalltalk has a good tradition of many small windows (SDI - single document interface) with all the inspectors, explorer, message traces, Monticello windows, etc. But suum cuique - the InspectorBrowser as a fusion of inspector + browser already exist, and I don't see any harm in improving/extending this tool. You are also making a very good point in providing a view to explore state and behavior of an object at the same time. You do not even need to restrict the target group of this tool to beginners - experts could benefit from a more efficient tooling as well. :-)
> > 
> > Here are some pointers to related work, just for your inspiration (see also the attached screenshots):
> > 
> > * I recommend you try out Autocompletion [1] if you haven't yet. It should help you reach your goal "if you want to try sending messages to the inspected object you don't have to look for which messages the object responds to", too. :-) It uses some heuristics for guessing the type of the current expression and will suggest you selectors from the relevant object's class hierarchy.
> > * In the context of SimulationStudio, I'm currently working on two approaches for making protocol exploration more straightforward. First, there is a (yet unpublished) prototype that upgrades the type-guessing of Autocompletion by evaluating the expression in a Sandbox. Second, I have built another (yet unpublished :/) prototype of an API Explorer that comes with a similar idea as the Object Inquirer but tries to display a preview of the result of sending each selector to the receiver (especially helpful for classes that provide many complex getters). I hope to get both prototypes published soon(tm). ;-)
> > 
> > - Similarly to the inspectors in the debugger, the separate code pane in the object inquirer is not strictly required. You can also evaluate/print expressions in the value pane against the same receiver. I think it would not be necessary to add the second pane in the object inquirer, do you see any benefit from it? Otherwise, we would have a chance to simplify the UI a little bit which is rather complex right the moment.
> > 
> > - Third, why subclass from the InspectorBrowser rather than extending it? I would vote for integrating your changes right into the InspectorBrowser, and *maybe* renaming it to Inquirer. Maybe a few people are familiar with the old name. Maybe extending the "do-it" vocabulary (print it, inspect it, explore it) with another verb (inquire it) would add too much complexity to the domaining, but not sure about this. Alternatively, we could at least make the refurbished InspectorBrowser available from the inspector/explorer menu. Maybe we could even build a preference that automatically opens an InspectorBrowser for "inspect it" rather than a simple inspector.
> > 
> > Have a nice christmas, too! :-)
> > 
> > Best,
> > Christoph
> > 
> > [1] https://github.com/LeonMatthes/Autocompletion
> > 
> > ---
> > Sent from Squeak Inbox Talk
> > 
> > On 2021-12-25T17:55:01+01:00, mail at jaromir.net wrote:
> > 
> > > Hi Marcel, Christoph and all,
> > > 
> > > For your consideration:
> > > 
> > > I've extended the Inspector Browser a bit to include the position of the object's class in the hierarchy, and added an inspector code pane. The implementation is subclassed off InspectorBrowser to the new ObjectInquirer class.
> > > 
> > > The goal is to help beginners who are new to OOP and Smalltalk to better grasp the concept of "object"; the learner should be able to literally see the whole object, i.e. its states (variables) and its behaviors (methods) tied together rather than separated; the current Inspector (or Explorer) displays only the object states, while the Class Browser (or Hierarchy Browser) displays only the behaviors (and inheritance hierarchy); as a pro you're probably thinking: "...and where's the problem?", but if you're just beginning with OOP, it makes it unnecessarily difficult to learn.
> > > 
> > > According to dictionary.com an inquirer is "a person who asks a question or seeks to learn about something" so the name Object Inquirer seemed a good candidate :)
> > > 
> > > If you want to try sending messages to the inspected object you don't have to look for which messages the object responds to; you have them in front of you, including all inherited messages. You can also immediately see where in the hierachy the inspected object belongs - very helpful for a beginner. 
> > > 
> > > And if you're wondering where all the state variables come from, again you can find out right away which superclasses add which variables.
> > > 
> > > Try to compare e.g. "Transcript inspect" and "Transcript inquire". (screenshots attached)
> > > 
> > > I could go on and on about why I think this might be useful for beginners... I just wish I had such a tool when I started with OOP and Smalltalk :)
> > > 
> > > As an exercise, I've also implemented the Object >> #inquire method, a yellow button menu item 'inquire it (Q)' and the CMD+Shift+Q shortcut to make Inquirer use consistent with Inspector and Explorer (to make the shortcut work, just do-it: SmalltalkEditor initialize).
> > > 
> > > I'd appreciate your opinions if you considered such a tool useful.
> > > 
> > > Merry Christmas!
> > > 
> > > 
> > > ~~~
> > > ^[^    Jaromir
> > > 
> > > Sent from Squeak Inbox Talk
> > > ["ProjectObjectInquirer.1.cs"]
> > > ["Object Inquirer.png"]
> > > -------------- next part --------------
> > > A non-text attachment was scrubbed...
> > > Name: ProjectObjectInquirer.1.cs
> > > Type: application/octet-stream
> > > Size: 5850 bytes
> > > Desc: not available
> > > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211225/90b5268a/attachment-0002.obj>
> > > -------------- next part --------------
> > > A non-text attachment was scrubbed...
> > > Name: Object Inquirer.png
> > > Type: application/octet-stream
> > > Size: 130512 bytes
> > > Desc: not available
> > > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211225/90b5268a/attachment-0003.obj>
> > > 
> > > 
> > ["Autocompletion.png"]
> > ["APIExplorer.png"]
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211226/8d47b028/attachment-0001.html>
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: Autocompletion.png
> > Type: application/octet-stream
> > Size: 28438 bytes
> > Desc: not available
> > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211226/8d47b028/attachment-0002.obj>
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: APIExplorer.png
> > Type: application/octet-stream
> > Size: 138671 bytes
> > Desc: not available
> > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211226/8d47b028/attachment-0003.obj>
> > 
> >
> 
> 
["ObjectInquirerProject.2.cs"]
["ObjectInquirerProject.2.cs"]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ObjectInquirerProject.2.cs
Type: application/octet-stream
Size: 6161 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220206/b7f8bb1a/attachment.obj>