[squeak-dev] Inspector Browser based tool for beginners: Object Inquirer

christoph.thiede at student.hpi.uni-potsdam.de christoph.thiede at student.hpi.uni-potsdam.de
Sun Dec 26 15:24:38 UTC 2021


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>


More information about the Squeak-dev mailing list