Smalltalk › Cincom › VisualWorks

[PDP] could this be done?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Travis Griggs

[PDP] could this be done?

This is a nit. I admit. Don't take it too seriously. I wrote a test,
and then hit the debug button, and the debugger opened right away
(because that's what it does in SUnitToo) and I then hit define
method and defined the following method (a class side instance
creation method):

device: aDevice isOnline: aBoolean
^(super device: aDevice) isOnline: aBoolean

Neither device: in the super class or isOnline: on the instance side
had been defined yet, I intended to fix them as I went. So the super
device: failed. And implemented it. But it did not accept it on the
super class, but rather the receiver class. The weird thing is, when
I hit continue, it continued on through that code. It actually worked
(though it was not super) and let me do the normal define method for
the instance side isOnline:. The test then completed green.

When I reran the test though, it of course failed, because device:
wasn't available at the super level:. In retrospect, I didn't
actually need the super. It was more me informing the debugger that's
where I was going to implement it at. It woulda been cool though if
it could have realized it was a super send and compiled it in the
parent class. Or if there were a way in the debugger when defining a
method to indicate that it should be compiled in a super class (but
not in such a way that it hindered the normal common operation).

--
Travis Griggs
Objologist
"It had better be a pretty good meeting, to be better than no meeting
at all" - Boyd K Packer

-----------------------------------------
DISCLAIMER: This email is bound by the terms and conditions
described at
http://www.key.net/disclaimer.htm

Boris Popov, DeepCove Labs (SNN)

RE: [PDP] could this be done?

You'd also have to pick *which* super to define your method on :)

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: Travis Griggs [mailto:[hidden email]]
> Sent: Wednesday, February 08, 2006 4:13 PM
> To: VW NC
> Subject: [PDP] could this be done?
>
> This is a nit. I admit. Don't take it too seriously. I wrote
> a test, and then hit the debug button, and the debugger
> opened right away (because that's what it does in SUnitToo)
> and I then hit define method and defined the following method
> (a class side instance creation method):
>
> device: aDevice isOnline: aBoolean
> ^(super device: aDevice) isOnline: aBoolean
>
> Neither device: in the super class or isOnline: on the
> instance side had been defined yet, I intended to fix them as
> I went. So the super
> device: failed. And implemented it. But it did not accept it
> on the super class, but rather the receiver class. The weird
> thing is, when I hit continue, it continued on through that
> code. It actually worked (though it was not super) and let me
> do the normal define method for the instance side isOnline:.
> The test then completed green.
>
> When I reran the test though, it of course failed, because device:
> wasn't available at the super level:. In retrospect, I didn't
> actually need the super. It was more me informing the
> debugger that's where I was going to implement it at. It
> woulda been cool though if it could have realized it was a
> super send and compiled it in the parent class. Or if there
> were a way in the debugger when defining a method to indicate
> that it should be compiled in a super class (but not in such
> a way that it hindered the normal common operation).
>
> --
> Travis Griggs
> Objologist
> "It had better be a pretty good meeting, to be better than no
> meeting at all" - Boyd K Packer
>
>
>
> -----------------------------------------
> DISCLAIMER: This email is bound by the terms and conditions
> described at http://www.key.net/disclaimer.htm
>
>

smime.p7s (4K) Download Attachment

Randy Coulman

Re: [PDP] could this be done?

In reply to this post by Travis Griggs

On 2/8/06, Travis Griggs <[hidden email]> wrote:

When I reran the test though, it of course failed, because device:
wasn't available at the super level:. In retrospect, I didn't
actually need the super. It was more me informing the debugger that's
where I was going to implement it at. It woulda been cool though if
it could have realized it was a super send and compiled it in the
parent class. Or if there were a way in the debugger when defining a
method to indicate that it should be compiled in a super class (but
not in such a way that it hindered the normal common operation).

Dolphin 5 does this with a cascading menu off of "Implement in". The top choice in the menu (and default action) is the class of the receiver, and all of its superclasses appear below a separator, working up the class hierarchy (so Object is at the bottom of the list).

Probably the extra sub-menu doesn't meet your "not in such a way that it hindered the normal common operation" requirement, but it is a way of getting what you want here.

Randy
--
Randy Coulman
[hidden email]

Reinout Heeck-2

Re: [PDP] could this be done?

Randy Coulman wrote:
> Dolphin 5 does this with a cascading menu off of "Implement in". The
> top choice in the menu (and default action) is the class of the
> receiver, and all of its superclasses appear below a separator, working
> up the class hierarchy (so Object is at the bottom of the list).

I would like to see this in the PDP as well. Very often I will 'sketch'
code in the debugger this way, but I end up switching to the browser
because the debugger won't allow me to implement the new method high
enough in the hierarchy.

--
Reinout Heeck
Idle curiosity is the enemy of a quiet life.

Terry Raymond

RE: [PDP] could this be done? - FileIns attached

In reply to this post by Travis Griggs

Travis

Try out the zipped fileIns.

Terry

===========================================================
Terry Raymond Smalltalk Professional Debug Package
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI 02878
(401) 624-4517 [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

> -----Original Message-----
> From: Travis Griggs [mailto:[hidden email]]
> Sent: Wednesday, February 08, 2006 7:13 PM
> To: VW NC
> Subject: [PDP] could this be done?
>
> This is a nit. I admit. Don't take it too seriously. I wrote a test,
> and then hit the debug button, and the debugger opened right away
> (because that's what it does in SUnitToo) and I then hit define
> method and defined the following method (a class side instance
> creation method):
>
> device: aDevice isOnline: aBoolean
> ^(super device: aDevice) isOnline: aBoolean
>
> Neither device: in the super class or isOnline: on the instance side
> had been defined yet, I intended to fix them as I went. So the super
> device: failed. And implemented it. But it did not accept it on the
> super class, but rather the receiver class. The weird thing is, when
> I hit continue, it continued on through that code. It actually worked
> (though it was not super) and let me do the normal define method for
> the instance side isOnline:. The test then completed green.
>
> When I reran the test though, it of course failed, because device:
> wasn't available at the super level:. In retrospect, I didn't
> actually need the super. It was more me informing the debugger that's
> where I was going to implement it at. It woulda been cool though if
> it could have realized it was a super send and compiled it in the
> parent class. Or if there were a way in the debugger when defining a
> method to indicate that it should be compiled in a super class (but
> not in such a way that it hindered the normal common operation).
>
> --
> Travis Griggs
> Objologist
> "It had better be a pretty good meeting, to be better than no meeting
> at all" - Boyd K Packer
>
>
>
> -----------------------------------------
> DISCLAIMER: This email is bound by the terms and conditions
> described at
> http://www.key.net/disclaimer.htm

DefineInSuper.zip (3K) Download Attachment