Style - OO vs User-Defined Functions

From: William M. Klein (wmklein_at_nospam.netcom.com)
Date: 12/08/04 

Date: Wed, 08 Dec 2004 22:56:14 GMT

We (CLC) are having SO much fun (???) talking about "style" issues, I thought
that I would start a new thread on another "style" issue.

First, let me state that I *do* believe that what I am talking about in this
note is a CHOICE without a "right or wrong" answer, but it is also an issue that
MIGHT be worth thinking about (sooner than later).

The question is:
    Given a FULLY CONFORMING 2002 COBOL compiler (a thing that doesn't exist
today - that I know of), then what would be the factors that one might consider
in deciding when a piece of new "procedural logic" should be created in OO and
when should it be a user-defined function?

What I hope to do in this note is to state some of the things that *I* think
might be such factors.

1) First thing that comes to mind is the fact that (to me) there may be a
difference in
    - the code (and requirements for the programmer) who creates the new
"procedural logic"
        versus
    - the code (and requirements for the programmer) who USES the new
"procedural logic"

Specifically, creating a "user-defined function" is EASY for anyone who knows
how to "code" a subprogram. In fact, the only real difference between a
subprogram's source code and a user-defined function is the use of FUNCTION-ID
paragraph and END FUNCTION marker versus PROGRAM-ID and END PROGRAM. There may
be *some* semantic implications (last-used state - for example) that need to be
considered and some "outside" things like function prototypes and repositories,
but BASICALLY the coding is the same. In fact, many subprograms CAN be made
into a user-defined function (assuming they have the '02 Standard "RETURNING"
phrase) simply via a COPY REPLACING or REPLACE statement.

On the other hand, creating an OO class requires LOTS of "new" syntax and
understanding. (Different and "more complex" source structure - or at least
"more complex" until you have used it - IMHO).

2) Clearly, the "design" issues of user-defined functions (which SHOULD be a
single procedural task) versus creating an OO class (with data, methods, to
encapsulate ALL of the "relevant" attributes/actions of an "object") is a very
different task. To me, user-defined functions require no new "design
methodology" while OO done withOUT new methodology is a "bad"idea - if not
doomed from the start.

3) Assuming (big assumption !!!) that someone has already created a Class (or a
class library) or a function (or function library), then EITHER seems (to me) to
be pretty easy to use.

  OO
    - INVOKE (out-of-line)
    - :: (in-line)
  User-Defined Function
    - <function> (in-line only, use CALL and subprogram for out-of-line)

4) What about interfacing with other languages:
     Interestingly enough, there doesn't seem to be much "literature" (that I am
aware of) about using "user-defined functions" from non-COBOL libraries ....
EVEN THOUGH functions (in such languages as C) have been around for years
(decades). I think - but won't swear to it that this is because this has been
available "transparently" to COBOL vendors with a RETURNING extension for years.
No one really thought about this as something needing to be "documented". For
example ...
    Call "Some_C_Function"
           Using ABC
           Returning XYZ
...
    But now (possibly?)
       Move Function "Some_C_Function" (ABC) to Other-Field *> with FUNCTION
now optional word

(of course the new '02 "CALL-CONVENTION" may be relevant here too).

On the other hand, there is LOTS of discussion of using non-COBOL OO Class
libraries (including inheriting from them and overriding their methods) from
"new" OO COBOL.

My guess (based solely on impression - no fact) is that *TODAY* there is more
NEW development of non-COBOL "class libraries" than there is of "general purpose
functions" (API's). However, there are certainly PLENTY of "functions"
available in many operating systems and environments.

5) If one has an "experienced" COBOL programmer who is NOT familiar with coding
EITHER OO or user-defined functions, then there are questions of:
   - are they picking up one or the other "for the learning experience"?
   - which is likely to be more portable to other COBOL compilers (with PARTIAL
implementations of the '02 Standard)
   - is this a "one-off" or something that is the start of a new
shop/application approach (and if so, which will meet the greater set of
application needs)

6) Are there issues (for this compiler and Operating System) concerning "late
binding" versus "early binding" (link-editing, whatever) and if so, are there
testing and "audit trail" implications for one or both of the approaches? (i.e.
if one is creating a "general purpose user-defined function" or new OO Class,
then how easy will it to be to "maintain" with adequate but not burdensome
restrictions for other/all systems using the new "code").

7) COBOL does *not* have easy ways to define truly "arbitrary" user-defined
function input parameters (i.e issues with the ANYLENGTH, OPTIONAL, - not to
mention different classes, categories, and PICTUREs). On the other hand, OO can
(with KNOWLEDGEABLE coders - IMHO) handle a variety of "inputs" to the same (or
similar) methods. (Personally, I don't think there is any way in STANDARD COBOL
to create the ORD-MIN intrinsic function - for example - in COBOL. Creating an
ORD-MIN-OO "method" for DIFFERENT object types would, however, be if not simple,
possible - I think.)

    ****

There are probably LOTS of other factors that one might consider for this STYLE
choice, but I thought others might want to think about (talk about) this.

I guess that my SUGGESTION would be that (assuming that BOTH features were
available *and* that you had equally skilled programmers available) then ...

   If you have a SINGLE procedural logic "snippet" that you want to make
"generally available" *and* it has well defined (and not variable) input, then a
user-defined function would be a good choice (and would have SOME advantages
over a subprogram)

  If, on the other hand, you have a "series" of similar actions that you want to
perform on a specific (or set of similar) "objects" then creating an OO Class
would be a good choice. 

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