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