Confessions of an "OO Foreigner"

From: William M. Klein (wmklein_at_nospam.netcom.com)
Date: 12/30/03 

Date: Tue, 30 Dec 2003 00:09:16 GMT

Given the recent OO (understanding, advantages, etc) threads, I thought I would
start a NEW thread with my (very personal) background and interactions with OO.
I don't know if others want to "join in" or not - but I thought this MIGHT help
those reading this newsgroup in evaluating my participation (and often lack
thereof) in these threads.

First and foremost - and the reason I used the subject that I did -
  I have NEVER produced one (much less more than one) "production application"
using OO (COBOL or otherwise).

For those who don't "know me," in actual fact it has been WELL over a decade
since I created any "production" application (either procedural or OO - either
in COBOL or any other programming language/tool).

I have an academic background in linguistics, and as such, I really, REALLY
understand the difference between "knowing" a ("natural") language well enough
to translate (to or from) and actually THINKING in that language. As long as
you still "translate" in your mind, then you simply do NOT know the other
language. As far as programming languages go, I am truly mono-lingual. The
*only* programming language that I "think in" is COBOL - although I have
"studied" a number of other languages (including IBM S/3xx Assembler, PL/I, C -
IBM 4GLs Telon, ADF, CSP).

Therefore, it is my strongest possible view that *MY* opinions on OO (both
methodology and languages) is that of a "medium well informed" foreigner.

  ***

As far as my background with OO, it is as close to "unique" as one can get. I
"learned" OO as a "COBOL language designer. My first experience was within Micro
Focus when they were "adding" OO syntax to their products and then (almost - but
not quite simultaneously) with ANSI/ISO as they were adding OO syntax to
"Standard COBOL". These means that I was "told" what functionality was
"required" for an OO programming language and my task was to help "design" what
was the best way to provide the desired functionality into COBOL - in a manner
"consistent" with existing COBOL features. I should clarify here, that both
within Micro Focus *and* the ANSI/ISO groups there WERE people who actually
"thought" in OO (non-COBOL) while this design work was being done, so you should
NOT blame (if you don't like it) COBOL OO design on a lot of "OO ignoramuses" -
even thought *I* was one.

One of the issues that I worked on (fought about - and STILL think that I might
have been correct about - even though I lost) was the very "INVOKE" statement
that Peter mentioned in another thread. Ignoring some of the (less often used)
variations, the BASIC structure of the currently approved INVOKE statement in
COBOL Is:

   INVOKE specific-object-reference-data-item specific-method-name
                USING various-parameter-by-CONTENT/REFERENCE/VALUE
                RETURNING returned-value-data-item

The questions that I raised in both Micro Focus (hereafter MF - which in this
note doesn't mean "mainframe") and J4/WG4 was:

 - Is INVOKE really the correct verb?
 - Are you invoking the object or the method?
 - Why can't you use a data-name for the method-name (similar to data-name in a
CALL statement) for "most cases"?
 - Shouldn't there be (at least an optional keyword) between the
object-reference and the method names?

To explain why I asked these questions (and never really received adequate IMHO
replies), let me explain what MY understanding of OO says that the INVOKE
statement is "trying" to do (in a rather VERBOSE way). I think it is intended
to say:

 Send a message to a specific instance of OBJECT1 that it should
   Perform the action METHOD1 upon itself (whatever that means to an object of
OBJECT type)
   (optionally) Using any PARAMETERS-N
   (optionally) Returning a value in RETURN-PARAMETER-N

Alternatively worded, it means to

  Activate METHOD1 (whatever that means for an object of the type of OBJECT1)
    Upon the specific instance of OBJECT1 specified
   (optionally) Using any PARAMETERS-N
   (optionally) Returning a value in RETURN-PARAMETER-N

The following are the definitions of "INVOKE" from the "American Heritage"
Dictionary (and I don't think that common British usage is much different):

"Inflected forms: in·voked, in·vok·ing, in·vokes
1. To call on (a higher power) for assistance, support, or inspiration:
"Stretching out her hands she had the air of a Greek woman who invoked a deity"
(Ford Madox Ford). 2. To appeal to or cite in support or justification. 3. To
call for earnestly; solicit: invoked the help of a passing motorist. 4. To
summon with incantations; conjure. 5. To resort to; use or apply: "Shamelessly,
he invokes coincidence to achieve ironic effect" (Newsweek). 6. Computer Science
To activate or start (a program, for example)."

Notice that the LAST definition includes a computer sicene meaning that would
IMPLY (at least to me) that what should be "invoked" is the METHOD and not the
OBJECT-REFERENCE if "invoke" is the correct word at all.

Therefore, I still maintain that if the syntax ends up with the object-reference
as first, a verb like "TRANSMIT TO" or even a "verb" of MESSAGE <to> would be
better (more COBOL like) than INVOKE.

Well, I lost <G> that battle and we ended up with INVOKE. Once we have INVOKE
then the question is - do we INVOKE the method or the object-reference. As I
indicated above, what the "computer science" meaning of INVOKE implies (to me)
is that we SHOULD have INVOKED the method, giving syntax like,

   INVOKE method-name UPON object-reference-name USING ...

Well, I lost <G> that battle and we ended up with INVOKE object-reference. Once
we had "object-reference" as the object (grammatical usage) of the INVOKE verb,
then I though we AT LEAST should have an OPTIONAL keyword explaining "what"
(adverbial) we wanted to do with this "second" thing, the method-name. What I
wanted was something like

  INVOKE object-reference <WITH> method-name USING ....

Well, I lost <G> that battle and we ended up with two "nouns" following the
INVOKE verb - with two VERY different meanings and no preposition between them.
As far as I know, this is the ONLY time this exists in COBOL (which is English
like) and totally (IMHO) obscures what the INVOKE statement does!!!

Finally, I questioned WHY the method-name couldn't be a data-name (rather than a
literal). Eventually (not in the initial design) this was "allowed" for the
case where a "universal object reference" is used. However, it seems to me that
just like a "CALL data-name" statement allows for "logic" decisions to be made
for what module should be called at run-time, I didn't (and still don't)
understand WHY a program shouldn't be allowed to decide "at run-time" which
method (for a specific object-reference) is to be used in the INVOKE statement.
OBVIOUSLY, this would require "late binding" - but COBOL already *allows* this
(or so I understand), so I didn't and don't understand why this wasn't allowed -
but I lost that battle too.

So, ...
  All of you who "think in OO" - does the above show that I "understood" OO and
what "INVOKE" should do - or am I still a foreigner trying to "translate" your
needs into my language????

  ****

Now back to my "confessions" ...

Coming from an IBM mainframe background ...

I have always been used to "multi-tasking" (required in a CICS online
environment - even when COBOL made it difficult) and more to the point of
another thread "re-entrant" code where multiple instances of the same "logic"
must be allowed to run simultaneously (and efficiently and with both "separate"
and "shared" data). I won't go into the details of how both CICS and IBM (DC
particularly) have supported this functionality for as long as I have worked
with them, but needless to say, they have. Therefore, I haven't (thinking as I
do in traditional COBOL-think), I don't find anything NEW (other than syntax) in
the "functionality" for this in OO COBOL as compared to "traditional" (IBM
online) COBOL environments.

It should be noted here, that CICS programming (at least as long as I have known
it - and I cam in when macro was first being "phased out") has ALWAYS been
"event driven". So for those using OO in a GUI (or possibly other)
environments, being "event driven" is no "biggy" change in what COBOL can (and
does) do.

Similarly, (and I do NOT confuse GUI with OO - as you can do GUI without OO and
OO without GUI - but the two are often "combined"), as I stated in another
thread, I have been involved with

    object-action
        versus
    action-object

paradigm decisions and evaluations for decades now. I "get" the difference and
I can see PROs and CONs for each and how to design either (using traditional
COBOL - as well as any OO language including COBOL).

  ***

So to conclude, as I stated in another thread, I *know* I have not internalized
OO (COBOL or otherwise) - much less "components" (as distinct from "modular")
design. I know that when I am asking about, answer about, or just commenting on
OO (COBOL or not) I am doing so as a "foreigner" looking from the outside. Only
if I did (or had to) implement at least two applications in OO would I think
that I *might* start thinking in OO.

I hope that this (medium long) post is useful to some in understanding where I
come from and more importantly in evaluating your own starting point for OO
discussions. 

-- 
Bill Klein
 wmklein <at> ix.netcom.com

Relevant Pages

  • Re: Confessions of an "OO Foreigner"
    ... > in COBOL or any other programming language/tool). ... > to translate and actually THINKING in that language. ... > - Is INVOKE really the correct verb? ... when the High Priests of COBOL guarded the Holy Source Code and made ...
    (comp.lang.cobol)
  • Re: Confessions of an "OO Foreigner"
    ... There is no need to use verb INVOKE ... If INVOKE is used, which object does it belong to? ... > in COBOL or any other programming language/tool). ... > to translate and actually THINKING in that language. ...
    (comp.lang.cobol)
  • Re: invoking a method
    ... They pretty much all invoke methods in a somewhat similar format in that the object comes first, followed by the name of the method, followed by any parameters. ... MF COBOL ... Comments like "don't you have better things to do with your time then create yet another programming language" will be ignored. ... MOVE EMP1 TO ADD-KEY OF DISPLAYLIST. ...
    (comp.lang.cobol)
  • Re: Web Services and COBOL (Fairly long post, but I dont have time to write a proper article on it)
    ... Menu driven application - from the Trigger start the App ... interoperability in COBOL. ... invoke EventManager "new" returning os-EventManager ... However the web service, although being around 4000 lines of OO COBOL ...
    (comp.lang.cobol)
  • Re: Heres one problem
    ... So given your format, what percentage of COBOL programmers do you think actually give a picture of data items, WITHOUT a final period/full Stop? ... invoke os-Collection "finalize" ... invoke a-OrderedCollection "finalize" ... A tutorial should demonstrate best practices, ...
    (comp.lang.cobol)