Messaging vs. Methoding

Markus Kohler markus_kohler at hp.com
Tue Mar 23 17:04:43 UTC 1999


agree at 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. 


-- 
Markus Kohler  mailto:markus_kohler at hp.com





More information about the Squeak-dev mailing list