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

On Tue, May 19, 2015 at 8:50 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 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.

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..

>> 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

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...  :(