agree@carltonfields.com wrote:

I have found the discussions quite informative, and have surprised myself as I find me leaning away from changes to syntax and convention of Smalltalk-80 in favor of less invasive solutions. To that end, I found myself wishing for a better solution, but was unable to find it. I would appreciate the advice of Smalltalkers with more experience than I.

In building a module, I find myself wishing to provide broad functionality with a range of options, but also desiring to have the morass of options mostly hidden by use of highly common defaults. For the simplest example, consider this message from the rePlugin package:

    aString reMatch: pattern opt: oString from: begin to: end

This directs a search of the receiver for matches of patterns from the specified substring indices, using certain options specified by oString. Assume that this full functionality is all warranted and necessary. The problem is that users most frequently will call this by using:

    aString reMatch: pattern opt: ' ' from: 1 to: (aString size)

tending to make us want to provide:

    aString reMatch: pattern

with defaults for the opt:, from: and to: portions of the message. On the other hand, the other calls are not infrequent, leading us to want to provide message for EVERY combination, in this case a total of 8 messages. Worse, every new degree of freedom requires another doubling of the message count. In many cases, each of these messages simply call the "most heavily specified" version, using the appropriate defaults.

This leads to lots of messages, and IMHO, aesthetically too many. Practically, managing new factorings becomes unwieldy and error-prone. In languages such as Python, methods can be defined to have a plurality of default keywords, such as:

    reMatch(self,pattern,opt='',from=1,to=self.size())

which has the effect of the combinatorial expansion of independent messages, but the virtue of having the code handled all in one place, and requires no "pure glue" messages. (Actually, I'm not sure that the default for to can be specified in this way. You may need to default to nil and put the logic in the preamble of the method.)

I think this is a good thing. I note that from a messaging standpoint, this approach requires no change in syntax (as would the Python keyword parameters, for example). I presume that the reason this isn't done in Smalltalk is that dynamic lookups of methods would be complicated and slowed thereby. Still, it seems to me that the a method lookup process needn't be impeded by default keywords -- the compiler can still generate each method selector independently, having them all point to the same code, or perhaps code that performs the "glue assignments," followed by a message to the "fully specified" procedure. Of course, browsers would need to know that removing or modifying such a message would require removal or modification of ALL of the "derivative" methods, but that doesn't seem too complex. It would be "nice," IMHO, to be able to specify every one of the messages above with a single message (from a browsing perspective) having a declaration, perhaps, of the form:

    reMatch: pattern opt: oString :=  ' ' from: begin := 1 to: to := (self size)

or equivalent (and perhaps better-looking) syntax?

I presume that this has all been considered and weighed before. What am I missing?

IMHO the main problem is that it can get complicated. What if in your example the message reMatch: opt: already exists. Since you cannot know for sure who is the receiver of the message you will not know if code has to be generated for this send or not.

Should I have better factored the design?

In this case I think it's ok. I would only implement only the most frequently used messages. If a user really needs another message frequently sHe can still implement it in a few seconds.

As soon as your parameter list gets even longer you should think about encapsulating several parameters into an object. You could then create an 'OptionObject' that would have default values when created. Another approach would be to pass a dictionary with the the keys being the message identifiers and the values being the values for the options. Not very efficient of course unless the compiler is smart enough to avoid creating the dictionary all the time.

Is the keyword defaults approach practical (or even desirable) in Squeak? Would it be straightforward to implement? How would you go about it?

It's sounds difficult to me. Also my experience with the C++ default parameter mechanism, which is less powerfull, is that it's not worth the effort and makes reading code more difficult.

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

Some people seem to like this concept and other seem to not. As far as I know nobody has every actually tried to implement it but I think both parts of his proposal would be relatively easy to implement in Squeak primarily with a little compiler hacking. Note that while he proposes a virtual machine change to support the variable args I believe that it could be prototyped strictly using #doesNotUnderstand:

Allen_Wirfs-Brock@Instantiations.com