Why does debugger browse open on Object?
Hi - I've always meant to ask this question as it often catches me out. When you get a typical debugger on doesNotUnderstood: I find that typically I've muddled up a method name - so I want to quickly browse the receiver of my mistake and understand what methods it actually has that I can use. It seems that the browse button is exactly that, and the debugger helpfully shows MyClass(Object) doesNotUnderstand.... But browse actually opens on Object >>doesNotUnderstand: which while technically correct is not really that helpful. Why isn't there an easy way to open a browser on the real receiver of the message? Am I missing an obvious button, or is it really use Spotter and retype the name of the class? Interestingly - Create does the useful thing to create a method where you want? It seems so obvious, but most Smalltalks seem to adopt this approach? I guess I can add it - but surprised I have to really. Tim Sent from my iPhone
Hi Tim, all 2017-07-19 14:34 GMT-03:00 Tim Mackinnon <tim@testit.works>:
Hi - I've always meant to ask this question as it often catches me out.
When you get a typical debugger on doesNotUnderstood: I find that typically I've muddled up a method name - so I want to quickly browse the receiver of my mistake and understand what methods it actually has that I can use.
It seems that the browse button is exactly that, and the debugger helpfully shows MyClass(Object) doesNotUnderstand....
But browse actually opens on Object >>doesNotUnderstand: which while technically correct is not really that helpful.
Yesterday I was going to ask about this behavior, which has been nagging me for some time. I feel better reading it isn't only me who's sensitive to this friction. I don't understand why it is like this, but I assume it is because of a common behavior of browsing the receiver object in the stack frame without considering particular cases like Object>>doesNotUnderstand: I'll be happy if you find a way to implement it, as a System Option or via a shortcut modifier. Regards! Esteban A. Maringolo
Hi,
On 19 Jul 2017, at 19:56, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Hi Tim, all
2017-07-19 14:34 GMT-03:00 Tim Mackinnon <tim@testit.works>:
Hi - I've always meant to ask this question as it often catches me out.
When you get a typical debugger on doesNotUnderstood: I find that typically I've muddled up a method name - so I want to quickly browse the receiver of my mistake and understand what methods it actually has that I can use.
It seems that the browse button is exactly that, and the debugger helpfully shows MyClass(Object) doesNotUnderstand....
But browse actually opens on Object >>doesNotUnderstand: which while technically correct is not really that helpful.
Yesterday I was going to ask about this behavior, which has been nagging me for some time. I feel better reading it isn't only me who's sensitive to this friction.
I don't understand why it is like this, but I assume it is because of a common behavior of browsing the receiver object in the stack frame without considering particular cases like Object>>doesNotUnderstand:
I'll be happy if you find a way to implement it, as a System Option or via a shortcut modifier.
In fact, some years ago Camillo Bruni implemented a solution for this (it was opening the debugger in the place where the DNU was originated) but I think it was deactivated because people was not so happy. Maybe now is time to retry ;) Esteban
Regards!
Esteban A. Maringolo
It turns out it's trivial - just create a subclass of DebugAction (the create one has all the pieces you need). Not sure how you get an icon on the button (create doesn't either). Maybe I can propose it for 7. Possibly call it "browse receiver"? (A bit long though) Tim Sent from my iPhone
On 19 Jul 2017, at 19:55, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
On 19 Jul 2017, at 19:56, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Hi Tim, all
2017-07-19 14:34 GMT-03:00 Tim Mackinnon <tim@testit.works>:
Hi - I've always meant to ask this question as it often catches me out.
When you get a typical debugger on doesNotUnderstood: I find that typically I've muddled up a method name - so I want to quickly browse the receiver of my mistake and understand what methods it actually has that I can use.
It seems that the browse button is exactly that, and the debugger helpfully shows MyClass(Object) doesNotUnderstand....
But browse actually opens on Object >>doesNotUnderstand: which while technically correct is not really that helpful.
Yesterday I was going to ask about this behavior, which has been nagging me for some time. I feel better reading it isn't only me who's sensitive to this friction.
I don't understand why it is like this, but I assume it is because of a common behavior of browsing the receiver object in the stack frame without considering particular cases like Object>>doesNotUnderstand:
I'll be happy if you find a way to implement it, as a System Option or via a shortcut modifier.
In fact, some years ago Camillo Bruni implemented a solution for this (it was opening the debugger in the place where the DNU was originated) but I think it was deactivated because people was not so happy. Maybe now is time to retry ;)
Esteban
Regards!
Esteban A. Maringolo
Sure propose a fix. On Thu, Jul 20, 2017 at 12:31 AM, Tim Mackinnon <tim@testit.works> wrote:
It turns out it's trivial - just create a subclass of DebugAction (the create one has all the pieces you need).
Not sure how you get an icon on the button (create doesn't either).
Maybe I can propose it for 7.
Possibly call it "browse receiver"? (A bit long though)
Tim
Sent from my iPhone
On 19 Jul 2017, at 19:55, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
On 19 Jul 2017, at 19:56, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Hi Tim, all
2017-07-19 14:34 GMT-03:00 Tim Mackinnon <tim@testit.works>:
Hi - I've always meant to ask this question as it often catches me out.
When you get a typical debugger on doesNotUnderstood: I find that typically I've muddled up a method name - so I want to quickly browse the receiver of my mistake and understand what methods it actually has that I can use.
It seems that the browse button is exactly that, and the debugger helpfully shows MyClass(Object) doesNotUnderstand....
But browse actually opens on Object >>doesNotUnderstand: which while technically correct is not really that helpful.
Yesterday I was going to ask about this behavior, which has been nagging me for some time. I feel better reading it isn't only me who's sensitive to this friction.
I don't understand why it is like this, but I assume it is because of a common behavior of browsing the receiver object in the stack frame without considering particular cases like Object>>doesNotUnderstand:
I'll be happy if you find a way to implement it, as a System Option or via a shortcut modifier.
In fact, some years ago Camillo Bruni implemented a solution for this (it was opening the debugger in the place where the DNU was originated) but I think it was deactivated because people was not so happy. Maybe now is time to retry ;)
Esteban
Regards!
Esteban A. Maringolo
participants (4)
-
Esteban A. Maringolo -
Esteban Lorenzano -
Stephane Ducasse -
Tim Mackinnon