Dec 212017
Experiment in object oriented Clipper with O:Clip. Compares three approaches to a small program.
File OOPEXM.ZIP from The Programmer’s Corner in
Category Dbase Source Code
Experiment in object oriented Clipper with O:Clip. Compares three approaches to a small program.
File Name File Size Zip Size Zip Type
HBOOLEAN.PRG 1495 513 deflated
HDOSFILE.PRG 3240 1004 deflated
HFORM.PRG 3574 1132 deflated
HFORMXYZ.PRG 3009 1172 deflated
OBOOLEAN.PRG 1668 580 deflated
ODOSFILE.PRG 4268 1186 deflated
OFORM.PRG 4678 1416 deflated
OFORMXYZ.PRG 2875 1098 deflated
READ.ME 5282 2286 deflated
TFORMXYZ.PRG 6704 2036 deflated

Download File OOPEXM.ZIP Here

Contents of the READ.ME file


Paul Long

The other day, I wrote a simple DOS-file-to-.DBF data-conversion utility
for a client in Clipper 5.01, using Funcky for the ASCII file I/O. I
then downloaded OCLIP 1.0a, the latest version of the FREEWARE
object-oriented extension to Clipper 5.01, and rewrote the utility to be
object-oriented just to evaluate OCLIP. I produced three sets of source
files that solve my problem using three slightly different methods.
Then I measured the execution speed of each method. Below, I outline my
problem and solution, briefly describe each method, present the test
results, and list the files.

The source files are made available to show what the object-oriented
counterpart to a traditionally coded, real-world program looks like.

This is my first stab at OOP in Clipper; however, I have written large
and small systems using OOP. I've done OOP programming in C++ and C
(yes, C), and I've played around with Smalltalk V/286. I haven't
agonized over the code, so it may be a little ragged. Any comments are
quite welcome.


The client is presently able to print medical-claim forms with their
existing back-office medical system. They are able to direct the output
to a DOS file. The product we sell wants the same information, but in a
dBASE file. An additional problem is that each one-page form can
contain from 1 to 6 entries for services rendered, with each service
resulting in a record being written to the dBASE output file--there is a
one-to-many relationship between forms and dBASE records.

A custom utility that we write can convert the forms in the DOS file to
a dBASE file. Since we'll probably have to do this type of conversion
for other clients in the future, it would nice to make the code easy to


The first is traditional, non-OOP. All code is in one file.

The second is a hybrid. Code is separated into files according to the
"class" it serves. This is not "object-oriented," "class-based," or
"object-based," to use Dr. Peter Wegner's classifications. It's just
maybe a little better organization of the code; for that reason, it's
not that interesting.

The third way uses the same code separation as the hybrid, but it is
object-oriented. Using OCLIP, four classes are defined: Boolean is for
logical objects, DOSFile is for DOS ASCII files, Form is for
medical-claim forms, and XYZForm is a specialization of Form. The
DOSFile and Form classes contain a Boolean object as an instance
variable. The Form class also contains a DOSFile object.

Boolean and DOSFile are foundation classes that any basic class library
should contain. These should be more robust than what I'm presenting
here. For example, there is no write-record method in DOSFile because
my little program didn't need to write to DOS files. The missing
methods are easily added. Boolean is probably overkill, but I
thought... what the heck. Form is an abstract class of which no object
should be instantiated (created). It is merely intended to be used as a
superclass. A "template" class, so to speak. XYZForm is a subclass of
Form. It is a medical-claim form used by a particular "XYZ" health

There should clearly be more classes in my program. For example, .DBFs
are not represented by a class. Like DOSFile, this should be included
in a basic class library. As I said, this is an exercise in evaluating
OCLIP and OOP in Clipper in general, not in building a robust class
hierarchy. I would hope to _buy_ my foundation classes.


The ASCII input file is 816K. It contains 544 forms, with an average of
2 medical-services entries per form. Each service results in a record
being written so that 1089 records are written to the .DBF. The output
.DBF ends up being 94K. The tests were run on a 20Mhz 386DX clone with
all disk caching turned off. The machine was warm-booted before each
test. .EXE load time has been subtracted from the numbers. Time is in
Method Execution Time % Degradation

Object-oriented 2.66 - -
\ \
28 \
/ \
Hybrid 2.08 = 34
\ /
5 /
/ /
Traditional 1.98 - -
Degradation occurred from traditional to hybrid to object-oriented.
Just so you don't misread my chart.

I'm sure a lot of time was spent doing I/O, so an object-oriented
CPU-intensive program would experience greater degradation over its
traditional counterpart. But who writes those kinds of programs in
Clipper anyway?


This is a list of the files that are zipped together: This file

tformxyz.prg Traditional

hformxyz.prg Hybrid

oformxyz.prg Object-oriented

 December 21, 2017  Add comments

Leave a Reply