I substantially agree (after all, I am agree@carltonfields.com!) with Doug's remarks. I think that a purely mechanical means of implementing optional keywords so that from the programmer's point of view, it would be fully functional without any change whatsoever being necessary with regard the VM/messaging semantics. I particularly like Doug's suggestion that the class of extended messages be displayed with a single line in the browser. It seems like a minimal impact solution would be a fun task.
After steve pair's remarks, I have been thinking about the general case for refactoring in the absence of the modification, and there is at least one straightforward pattern solution:
Given "extended" message pattern for message A in class Foo
req1: rp1 req2: rp2 opt1: [op1 := d1] opt2: [op2 := d2]
Refactor as follows:
In Foo, put the messages:
req1: rp1 req2: rp2 opt1: op1 opt2: op2 "central code for the process"
and
optWithReq1: rp1 req2: rp2 ^FooOpt obj: self req1: rp1 req2: rp2
Then create Class FooOpt with instance variables: obj rp1 rp2 op1 op2
with setters for op1 and op2, of the form:
FooOpt>>op1: aValue op1 := value ^self "important -- see doit!"
FooOpt class will have a instance creation method
FooOpt>>obj: obj req1: rp1 req2: rp2
which sets obj, rp1 and rp2, returning a fooOpt, and also setting op1 and op2 to d1 and d2, respectively. Then, add message "doit" or the like to FooOpt, along the lines of:
FooOpt>>doit
^obj req1: rp1 req2: rp2 opt1: op1 opt2: op2
Of course, this can be aesthetically tuned to suit, and works well when there are a multiplicity of "ultimate" operations for the required object combination. The syntax:
(foo optWithReq1: rp1 req2: rp2) opt1: nondefault1 doit
Seems to me more workable than the approach taken by Steve, where the express creation of the option object with a "yourself" at the end seemed to me awkward.
This works particularly nicely where there are a hunk of "doit" operations, as in the RePlugin materials. Thus, we could have:
aString reMatch: pattern
for the simple case, and
(aString reWithPattern: pattern) opt: 'imsl'; from: 10; to: 20; collect: [:m | m match ]
for the more complex cases. I still prefer the "simpler" optional parm syntax of Python, but that ain't Smalltalk Squeak (yet!).
Andy (werdna@gate.net, when not at work).
-----Original Message----- From: MIME :dway@mat.net Sent: Thursday, March 25, 1999 1:05 AM To: squeak@cs.uiuc.edu Subject: Re: Messaging vs. Methoding
On Tue, 23 Mar 1999, Allen Wirfs-Brock wrote:
Brian Wilkerson once developed an interesting proposal for extending the message pattern with optional keywords and a variable numbers of repeated keywords. You can find his proposal at http://www.smalltalksystems.com/publications/varargs.pdf
A year or so ago I thought about what adding optional keyword messages to Smalltalk would be like and how it would work... Brian's proposal is pretty much in line with what I was thinking.
squeak-dev@lists.squeakfoundation.org