Actually, what Anders describes is a pattern which I followed in the regular expressions plugin.  We created two classes:

	RePattern
	ReMatch

An instance of RePattern represents the result of compiling a regular expression for matching purposes, such as:

	RePattern on: '\w+'

or using a convenience message added to class string:

	'\w+' asRePattern

That instance is then applied against an object string to accomplish the actual matching process, such as

	m := re search: searchString
or
	m := searchString reMatch: re

where the search: and reMatch: messages return nil if no match, or a ReMatch object otherwise.

When searching a string for matches of a pattern,  the user may be interested in all or specific portions of a complex variety of match results, such as for example, the match substring, the number of subgroups of the pattern contributing to that match and if contributed, what is the subgroup match substrings, the unmatched prefix, the unmatched suffix, indices for all of the above and so forth.

Moreover, computing all this information can be expensive both in time and space, so you want to be very, very lazy.  On the other hand, you don't want twenty-zillion different procedures for computing the basics either.  My solution (not really an original one) is to have the second class, ReMatch, which encapsulates but does not compute or retain more than the essential byproducts of the matching, and is then capable of answering queries about the details on a lazy basis.  If there is no match, ReMatch answers nil.  You can then either use the non-nil nature of the reply if all you wanted to know was the existence of the match, or you can keep the ReMatch object and query it for all (or none) of the details you might require.

My first solution was to return an array of strings, corresponding to the principal match and subgroup matches from the match operator.  The ugliness of this implementation dependent approach led me to discovering the virtues of this alternative approach.

-----Original Message-----
From:	MIME :sqrmax at cvtci.com.ar Sent:	Monday, March 22, 1999 9:35 AM
To:	kpgrant at mindspring.com
Cc:	squeak at cs.uiuc.edu
Subject:	Re: Squeak programming question

Hi.

> The only thing that occurs to me is something like:
> > ^((OrderedCollection new) add: myDictionary add: mySet)
> > and then disassemble the thing on the receiving side.  I'm
> not really crazy about this though.

Yep... it depends.

1. Rephrase as aCollectionClass with: firstObject with: secondObject. It's a bit
more elegant, and if you use Array then it's somewhat more efficient... but
still you're left with the parsing afterwards. Sometimes it's needed, though.

2. If the object answering that message is an algorithm, then model it as an
object of its own. For instance, think about matrix reduction. You give aMatrix
to aMatrixReducer, and then perform:

aMatrixReducer run.

By now it knows the reduced matrix, now it feels comfortable to make questions
like:

aMatrixReducer reducedMatrix
aMatrixReducer independentColumns
aMatrixReducer millisecondsToRun "it already knows, it's an algorithm"

Andres.


 << File: ENVELOPE.TXT >>