Hi Marcus,

On Sat, Nov 2, 2013 at 7:17 AM, Marcus Denker <marcus.denker@inria.fr> wrote:

On 01 Nov 2013, at 22:49, Tudor Girba <tudor@tudorgirba.com> wrote:

> Hi,
>
> I am trying to set the GTInspector as the default explorer.
>
> However, I see that the inspector registration has changed. It seems to me that registering to #objectExplorer has no effect. Instead, we are now sending #inspect: and #explore to the #inspector:
>
> Object>>explore
> � � � ^Smalltalk tools inspector explore: self
>
> I do not quite see the rationale behind the current design.

With the new inspector, the inspector and explorer are the same tool. If you open a normal inspector, you can even turn it into an explorer with a keyboard shortcut.
Therefore it makes conceptually no sense to have a #objectExplorer tool. There was a basicInspector in the tools, too, which is now gone.

Explorers are just special inspectors, like the special inspectors for CompiledMethod or Dictionary, just available for all classes.

I agree that the explorer is like the inspector. But, if now they are the same, I do not see why we need to distinguish between them. I would leave only #inspect (no more #explore) around.

However, a stripped down basic inspector can still be useful as a fallback solution in case the fancy one fails given that it relies on much more widgets that can cause exceptions. For example, try this in a fresh Pharo 3.0 image:

� � �Smalltalk tools explore

You will get an exception. Having a basic inspector around is useful in this case.

As it is now, the basic inspector is wrapped in a more complex widget which can induce errors in the future, and we get stuck. So, all in all, I argue that we need a basic inspector mapped on a more complicated keyboard shortcut.

> Furthermore, Smalltalk tools still has an entry for #objectExplorer:
> (Smalltalk tools instVarNamed: #tools) at: #objectExplorer ==> ObjectExplorer
>

It should not. I thought I removed it. ObjectExplorer should be removed eventually (it is now only used for the PointerExplorer, which is a subclass).

Yes, I know. I was just pointing this out to show that I looked and that I was not sure of the current state.

�

> Anyway, I added #inspect: and #explore: to GTInspector class, and I registered it as the #inspector. It seems fine, but the problem now is that the default Spec-based debugger relies on a #inspectorSpec method in the inspector class.
>
> This is highly problematic and I am stuck. I think we should not introduce Spec-specific requirements at such a basic level.
>

It should normally not �leak� that the inspector is implemented with Spec, you should be able to replace the inspector (via Smalltalk tools) with another one.
So this should be checked and fixed.

Ok.

�

But it is clear that we can not have all the tools �in a crap version in the kernel� and �that version that everyone uses�. This Philosophy is *wrong* just the same
for tools as it is for libraries.

+100. I completely agree that the core needs powerful tools. That is why I actually argued for Glamour in that base image a long time ago. I still want to make that argument, but this is a discussion for another time :).

Doru

�

� � � � Marcus

www.tudorgirba.com

"Every thing has its own flow"