Re: Confessions of an "OO Foreigner"
From: Thomas A. Li (tli_at_corporola.com)
Date: 12/30/03
- Next message: Judson McClendon: "Re: CoBOL moved to OO"
- Previous message: Doug Scott: "Re: CoBOL moved to OO"
- In reply to: William M. Klein: "Confessions of an "OO Foreigner""
- Next in thread: Peter E.C. Dashwood: "Re: Confessions of an "OO Foreigner""
- Reply: Peter E.C. Dashwood: "Re: Confessions of an "OO Foreigner""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 30 Dec 2003 14:58:52 GMT
I would prefer using
specific-object-reference.specific-method-name(various-parameter-by-CONTENT/
REFERENCE/VALUE)
where dot are used as in Java and C++. There is no need to use verb INVOKE
because it is self-evident from use of parenthesis and it is faster to type
in code.
If INVOKE is used, which object does it belong to?
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:Mm3Ib.25364$Pg1.10164@newsread1.news.pas.earthlink.net...
> 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
>
>
- Next message: Judson McClendon: "Re: CoBOL moved to OO"
- Previous message: Doug Scott: "Re: CoBOL moved to OO"
- In reply to: William M. Klein: "Confessions of an "OO Foreigner""
- Next in thread: Peter E.C. Dashwood: "Re: Confessions of an "OO Foreigner""
- Reply: Peter E.C. Dashwood: "Re: Confessions of an "OO Foreigner""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
