[Tools] (Object >> #inspect) now returns the tool instead of the object

Hi, there! :)

I just want to mention and explain, why (Object >> #inspect) now returns the tool window instead of the object as in 4.5.

The Tools package adds several convenient methods to the base system:

Object >> #explore
Object >> #inspect
Object >> #browse
Behavior >> #browse

All but #inspect returned the created tool. So I went for consistency. But in particular, those methods should return the tool because because otherwise the programmer has no simple means to access the created window/tool programmatically. Model and object are, however, always accessible (via #model or just #self).

So if you got code like this:

self someObjects add: myObject inspect.

Please change it to:

self someObjects add: myObject inspect; yourself.

Or even better to:

myObject inspect.
self someObjects add: myObject.

I think that it is good practice/style to use #yourself if you want to get the receiver back in a chain of calls:

self myMorphs add: (MyMorph new color: Color yellow; yourself).

Best,
Marcel

On Tue, May 19, 2015 at 01:50:07AM -0700, marcel.taeumel wrote:
Thanks for the explanation. I think that you made the right choice.

Dave

That logic is sound except from one POV:  which is that #inspect and
#explore are used as a debugging tools for _users_.  For years, I've
been able to simply put one word "inspect" in a strategic place in my
application code to help me debug it.  Now, I'm forced to add
parentheses, cascades and, in some cases, even temp vars (!!) just to
avoid getting a SystemWindow tangled up into my domain model.

For you as a UI-framework developer, I can understand there might be
case or two where you would want to debug SystemWindow stuff.  But
that is the 0.1% usage case.  The 99.9% usage case is Squeak users are
interacting with their own domain model and they want to use #inspect
as a debugging tool.

What do other Smalltalks return from #inspect?  If you want to be
consistent how about we be consistent with them?

On Tue, May 19, 2015 at 3:50 AM, marcel.taeumel <[hidden email]> wrote:

On 19.05.2015, at 18:21, Chris Muller <[hidden email]> wrote:
That's compatibility and portability, not consistency.
Alas, we seldom have them all.
-t

On Tue, May 19, 2015 at 11:55 AM, Tobias Pape <[hidden email]> wrote:
Well, compatibility and portability refers to production code.  If
we're talking about the classic Smalltalk debugging tool #inspect,
then that is about a consistency of user-experience between the
Smalltalk dialects.  For some things in Smalltalk, the code _is_ the
UI.  #inspect is one of those things (as is #printString).

> Alas, we seldom have them all.

But we can try.  :)  We know the use-case for wanting classic
#inspect, could you (or someone) articulate what is the use-case where
I would want a SystemWindow back from inspect?

On Tue, May 19, 2015 at 11:21:56AM -0500, Chris Muller wrote:
> That logic is sound except from one POV:  which is that #inspect and
> #explore are used as a debugging tools for _users_.  For years, I've
> been able to simply put one word "inspect" in a strategic place in my
> application code to help me debug it.  Now, I'm forced to add
> parentheses, cascades and, in some cases, even temp vars (!!) just to
> avoid getting a SystemWindow tangled up into my domain model.

I think that Marcel's design choice is right, even if it is inconvenient
for the use case that you describe. The reasons are:

1) It is consistent with the way tool building works in general.

2) It provides a useful return value for #inspect. Answering self is
not particularly useful, because I already knew that before I sent #inspect
to it. Answering the tool window is useful in various debugging scenarios,
and it is not otherwise accessible programatically.

>
> For you as a UI-framework developer, I can understand there might be
> case or two where you would want to debug SystemWindow stuff.  But
> that is the 0.1% usage case.  The 99.9% usage case is Squeak users are
> interacting with their own domain model and they want to use #inspect
> as a debugging tool.

For the use case of embedding #inspect into source code for purposes of
debugging, we could trivially add this to serve the same purpose:

   Object>>inspectYourself
       self inspect

>
> What do other Smalltalks return from #inspect?  If you want to be
> consistent how about we be consistent with them?

I do not usually find myself arguing in favor of breaking backward compatibility,
but in this case it makes sense and I think it is the right thing to do.

Dave

Hi Chris,

this sounds like a quite rare corner case for me. Yes, you should add paraenthesis and stuff in such a scenario.

Were do you got those statistics from? I would say that 99,98% of Squeak users *scnr* invoke #inspect with a DoIt and do not spread those into their code because those users do not know how often it is executed and will not spoil their GUI with numerous windows popping-up. ;-)

Best,
Marcel

> I think that Marcel's design choice is right, even if it is inconvenient
> for the use case that you describe. The reasons are:

+1

Stef

(also to manifest that I do appreciate the work that Marcel is doing)

Not a huge deal guys, but some comments still worth noting (below)...

On Tue, May 19, 2015 at 8:50 PM, David T. Lewis <[hidden email]> wrote:
It may be consistent with how we _want_ it to work, but the first few
examples I checked are all over the map..

       Browser open  "answers the new Browser model"
       ChangeSorter open   "answers the receiver class"
       Transcript open    "answers the receiver TranscriptStream instance"
       MCWorkingCopyBrowser open  "answers the receiver class"
       'abc' inspect   "answers a SystemWindow"
       .... ??

So, if we really care about consistency on this we probably should
decide what we want and clean these up at some point..

> 2) It provides a useful return value for #inspect. Answering self is
> not particularly useful, because I already knew that before I sent #inspect
> to it.

Answering self _is_ useful, I already explained why, but Marcel is
right, it is pretty rare that I use that particular debugging
technique.  But, for me at least, wanting a SystemWindow back is even
more rare..

The biggest advantage to your way is the opportunity to manipulate the
UI window, which we may want to do someday..

Or go the other way rather than break a 30-year Smalltalk legacy...?

     Object>>inspectWindow
         ^ ToolSet inspect: self

:)

At a minimum we should decide whether we want to return the UI or the
model.  From your logic, I guess it would be the UI since that
provides access to everything.  But at least several #open methods
currently seem to be returning the Model..

>> What do other Smalltalks return from #inspect?  If you want to be
>> consistent how about we be consistent with them?
>
> I do not usually find myself arguing in favor of breaking backward compatibility,
> but in this case it makes sense and I think it is the right thing to do.

I get your points, I just think this is kind of like Morph>>#flash --
I always considered it a *debugging tool* to help users develop their
apps, and so, for that reason, feel it does not need to follow the
same rules as application code -- e.g., a Delay in #flash would be
fine, but due to disagreement it remains "clean" but useless to this
day...  :(