Messaging vs. Methoding

agree at carltonfields.com agree at carltonfields.com
Tue Mar 23 16:14:24 UTC 1999


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?  Should I have better factored the design?  Is the keyword defaults approach practical (or even desirable) in Squeak?  Would it be straightforward to implement?  How would you go about it?





More information about the Squeak-dev mailing list