Re: Basement tinkerers and inventors



"tlmfru" <lacey@xxxxxxx> wrote in message
news:K_WCi.24945$Zk5.1860@xxxxxxxxxxxxxxx

Pete Dashwood <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
I'm working on a program to reformat documents such that all
occurrences
of
a word or phrase are listed, sentence by sentence, together. I'm
actually doing a treatise > > on roses and I find that the particular bits
of text I want to bring together are usually
scattered all over the place. It rapidly gets to be a pain to do it by
hand. Anybody know > > of a program or function that will do this?

PL

Have a look at a technique called "Keyword in Context" (KWIC) I think
IBM
originally developed it for searching tape files, but it is also very
effective for processing documents.

I used it many years ago for something very similar to what you are
describing, and wrote a COBOL implementation of it. (I might still have a
copy of the source code on a machine somewhere...I never throw away
anything
I wrote.)

Pete.

Zounds! I have actually heard of that but only in the context of an IBM
product that we discredited as much as possible - I was working for Univac
at the time and nothing IBM did was above contempt! So I never looked
into
it. Thanks for the tip.

But, damnation, if it does what I want, it means that somebody thought of
it, a long time ago, and that there probably isn't anything new in the
world
of programming! If so, you may be right in your contention that
everything
can be done using objects ...

Incidentally: harking back to our slight dispute on "never doing
maintenance": I once wrote an application to take data from time-clocks &
report on the results. After about 18 months, some of the clocks began to
duplicate the occasional raw data record. My solution was to compare the
record to the previous one & if they were the same to skip - this worked
because the clocks were polled one at a time and the employee/time/date
combination was unique. Whether or not they still do it I neither know
nor
care! With your philosophy, how would you have handled this?


My philosophy, huh? :-)

(Pops in ping-pong ball eyes, puts on saffron robe and adopts the lotus
position...)

Ah, Glasshopper, truly it is important to be still, as the stones do not
hear the babbling brook.

Listen, in the silence, to the sound of the time clock object collecting the
clock-ins. That is what it does.

See the report program, feeding on the stream of data from the clock-in
object. That is what it does.

But hark! Is that the sound of choking from the report program, what is it
spitting out? A duplicate record!

Perhaps age has worn away the reliabilty of the clock-in device, even as the
wind and rain tear down the mountains over time.

We could change the report program to ignore the surplus data, but would you
ask the leopard to change its spots because it has indigestion?

We could change the clock-in object to ignore the surplus data, but does the
worm become a snake?

We could have the clock-in devices checked and regulated and restore them,
even as the Spring restores the leaves of the mighty banyan.

This is the best solution, for it requires no software intervention, and
heals the deterioration in our devices.

But perhaps the clock devices are no longer supported, or the compay that
sold them to us has ceased to trade..

Then we must do what we can in software.

Even as the mountain streams provide the succulent crayfish that are not
found in the rivers, so we must look to the source of our solution. The
closer to the source the anomaly can be checked, the better for everything
that lives downstream, even the tributaries and feeds that have not formed
yet.

How to make the data palatable to the report program and make no change to
the Clock-in Class?

A new Class can be created with a few lines of code. It inherits all of the
methods of the Clock-in Class and overrides the one that returns the data to
a feeder (GetClockData), so that duplicates are ignored. Let's call it the
"Filter" Class. The report program now instantiates the filter object
instead of the clock-in object. The interface is exactly the same; it is a
one line change in the Data Divison of the report program, to point it to
the new .dll (The report program is a procedural program anyway and as such
will be subject to maintenance...but the idea is to minimise the
maintenance)

Any programs that use other methods in the clock-in object remain unscathed.
The clock-in class has not been changed. Any clients that use the
GetClockData method and cannot deal with duplicate data, can now use the
Filter Class override of it instead. No other methods have been changed, no
interfaces have been altered, everything works as it always has and no
regression testing is required.

Truly, Glasshopper, there are more things in my philosophy than you may
readily conceive...

Does the camel suffer because it is not a horse?

Bending the Tao of OO and components to contrived examples that are not OO
and component based is not a good way to understand the Tao of OO and
Components.

The coolness of the Lake is not experienced by looking at it.

Only when we enter the waters are we truly refreshed.

(Stands up, saffron robe falls off, revealing naked corpulence, takes out
ping-pong ball eyes, ... blushes and exits stage right, leaving room and
dignity behind...)

Pete.
--
"I used to write COBOL...now I can do anything."



.