The common way of handling this is to provide the most common options as
methods on String (i.e. #reMatch:), but encapsulate the less frequently used
options in some object (in which defalt values could be initilized).  I
don't know the details of your implementation, but the calling code could
look something like:

aString reMatchPattern:
	(RePattern new
		patternString: pattern;
		opt: oString;
		from: begin;
		to: end;
		yourself)

You then only need to specify the options that differ from the defaults.
When you find yourself providing many such methods (to set individual
options), it's probably a good indication that things are either factored
incorrectly (requiring a new object) or you're trying provide too much for
the user.

- Stephen

P.S.  For more clarity, you might even break out the options into
individual, settable instance variables.

> -----Original Message-----
> From: agree at carltonfields.com [mailto:agree at carltonfields.com]
> Sent: Tuesday, March 23, 1999 11:14 AM
> To: DanI at wdi.disney.com; kpgrant at mindspring.com
> Cc: squeak at cs.uiuc.edu
> Subject: Messaging vs. Methoding
>
>
> 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?
>