Refactoring for options (Was: Messaging vs. Methoding)
agree at carltonfields.com
agree at carltonfields.com
Thu Mar 25 17:30:42 UTC 1999
I substantially agree (after all, I am agree at 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 at gate.net, when not at work).
-----Original Message-----
From: MIME :dway at mat.net Sent: Thursday, March 25, 1999 1:05 AM
To: squeak at 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.
More information about the Squeak-dev
mailing list
|