On Friday, 96/01/19, Murray Lesser wrote to David Noon about "Pl/i
Miscellanea" as follows:

ML>   >rewrite ... to encapsulate the OS/2 API inside PL/I statements. I
ML>   >have given up hope of decent %include files from IBM. 
ML> 
ML>     I don't really understand what you mean by "encapsulate" in this
ML> sense.  In the PL/I utilities I have written, I have found it
ML> easier to declare the API calls as "external entry" in the program
ML> than to fight the %include files, but I don't feel that is entirely
ML> what you have in mind.

Hi Murray,

I am using the word "encapsulate" in much the same way as Bjarne
Stroustrup would when writing a C++ class library. By that, I mean
that the programmer would be shielded from the API by a coating of
syntactic sugar. Furthermore, the encapsulation should be capable of
"containing" the API's of other platforms, such as Win32. Since
data/code encapsulation is also on the cards, I guess that makes it a
"polymorphic" word. ... :-)

The approach I plan to take is to implement new statements that
provide for keyword parsing of parameters rather than simply
positional parameters, and expand as macros into the API calls by
placing the parameters into their correct positions for the paritcular
API. Such a statement might expand into multiple API calls.

Thus, you would not call an API, you would simply code a statement to
invoke it, rather like the READ FILE() statement hides the DosRead()
API (and a little bit more as well).

There could be a few additional surprises, too, such as conditions
being signalled for execption situations, sort of like ENDFILE() when a
READ FILE() statement encounters end of data.

ML> As I remember, you were going to write an
ML> essay on the subject for "The PL/I Connection."  When might we
ML> expect it?

I will start drafting the article in a few weeks' time, since I am up
to my eyelids in CICS/COBOL legacy code from hell at the moment. I
hope it makes the June edition of "PL/I Connection".

ML>     If you are going to write a new API-call library, I hope you will
ML> have the kindness to make it shareware.  I would pay up to $100
ML> (US) to register it, if the registration includes a printed manual. 

I was planning on freeware, but at that price it might be a tidy
little earner. Let's see, $200 with the taxes (U.S. withholding tax,
U.K. income tax) taken out ... hmmm, I'd better move to Monaco.

I'll see how it progresses. I mentioned it to Clem Clarke in this echo
over 2 years ago and I haven't written a line of it since, so it
hasn't progressed at all so far. I should really install a copy of
Windows NT so that I can assess portability to Win32c too.

ML>     Don't knock called assembler code!  I bought my PS/2 model 80-A71

Up until a few months ago I lived and breathed assembler. It pays
better than the other languages, but it's a tad harder to write and
debug. After dealing with legacy assembler, I find legacy COBOL a
breeze. [Although Intel assembler is rather easier to deal with than
mainframe assembler.]

Regards

Dave


 * KWQ/2 1.2i * Mr. Gates, if that's a feature, I dread to see the bugs.
--- Maximus/2 3.01