Hi
I wanted to port the MethodWrappers of John Brant to Squeak to learn a bit more the differecne between VW and Squeak and I discovered that there is no way (or I did not find it) like in VW to execute a method. In VW we can invoke a method by sending it the message valueWithReceiver: arguments: .
Is there any plans to introduce this in Squeak? In VW this is a primitive and it give a lot of power to build tracing, debugging....tools.
See http://st-www.cs.uiuc.edu/users/brant/Applications/MethodWrappers.html.
Stef
Stephane DUCASSE (ducasse@iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes
University of Bern, Institut fuer informatik and Mathematik IAM-SCG, 10 neubruckstrasse, CH-3012 Bern, Switzerland.
------=_NextPart_000_0052_01BF5140.66CF9460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit
Salut Stef!
Don't you think we could solve this by doing something along the lines of: CompiledMethod>> valueWithReceiver: aClass Arguments: argList | aProcess aContext | aContext _ MethodContext sender: thisContext sender receiver: aClass method: self arguments: argList. aProcess _ Process forContext: aContext priority: Processor activePriority. aProcess resume ?
Joyeux NoÎl et Bonne AnnÈe
Torge ----- Original Message ----- From: Stephane Ducasse ducasse@iam.unibe.ch To: squeak@cs.uiuc.edu Sent: Tuesday, December 28, 1999 11:35 AM Subject: CompiledMethod>>value:withArguments:
Hi
I wanted to port the MethodWrappers of John Brant to Squeak to learn a bit
more
the differecne between VW and Squeak and I discovered that there is no way (or I did not find it) like in VW to execute a method. In VW we can invoke a method by sending it the message valueWithReceiver: arguments: .
Is there any plans to introduce this in Squeak? In VW this is a primitive and it give a lot of power to build tracing, debugging....tools.
See
http://st-www.cs.uiuc.edu/users/brant/Applications/MethodWrappers.html.
Stef
Stephane DUCASSE (ducasse@iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes
University of Bern, Institut fuer informatik and Mathematik IAM-SCG, 10 neubruckstrasse, CH-3012 Bern, Switzerland.
------=_NextPart_000_0052_01BF5140.66CF9460 Content-Type: text/plain; name="CompiledMethod-valueWithReceive" ; x-mac-type="65417070" ; x-mac-creator="43534F6D" Content-Disposition: attachment; filename="CompiledMethod-valueWithReceive" Content-Transfer-Encoding: imap_stub
0,2676,2,487,0,
------=_NextPart_000_0052_01BF5140.66CF9460--
Don't you think we could solve this by doing something along the lines of: CompiledMethod>> valueWithReceiver: aClass Arguments: argList | aProcess aContext | aContext _ MethodContext sender: thisContext sender receiver: aClass method: self arguments: argList. aProcess _ Process forContext: aContext priority: Processor
activePriority.
aProcess resume ?
Method wrappers are an extremely useful technique to gather all kinds of run-time information, to implement wrappers, ... One of their main benefits is that they are sufficiently lightweight and fast to be really useful (e.g. I collect run-time type information, and the system still responds fairly well).
It seems to me that Squeak is missing in reflective facilities in message handling. For that matter, so are most Smalltalk VM's. For instance, I have never understood why we should rely on "#doesNotUnderstand:" to implement proxies instead of having more direct support for efficient, dynamic message handling. Seems kind of weird to implement e.g. a proxy's *intended* behavior in 'error handling' routines, not to mention the fact that we have to specify the behavior we do not want to inherit when subclassing nil, rather than being able to define (by enumeration, pattern matching, constraints, whatever...) the protocol we do want to intercept.
michel
===== mtilman@acm.org http://users.pandora.be/michel.tilman
squeak-dev@lists.squeakfoundation.org