Re: CALL using OMITTED
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 30 Sep 2008 14:17:29 +1300
"Frank Swarbrick" <Frank.Swarbrick@xxxxxxxxxxxxxx> wrote in message
news:48E118C2.6F0F.0085.0@xxxxxxxxxxxxxxxxx
You've highlighted something very important here, Frank.JamesOn 9/26/2008 at 8:43 PM, in message <p5hDk.137$J63.102@xxxxxxxxxxxx>,
J. Gavan<jgavandeletethis@xxxxxxx> wrote:
I'm fascinated that you always seem to go looking for problems that you
can create in COBOL. What's wrong with KISS ?
I am not looking for problems. (Well, not in this case, at least!) I am
looking for solutions.
I'm always looking for ways to make things more flexible and dynamic, and
I
look for ways that Cobol can help with this. I thought that this might be
one such case.
Simple is good. Simple and powerful is better.
So in both examples you have A, B, C and D as pic x(04). What's so
complicated about :-
move spaces to C and D, when appropriate, before you do the CALL
(or any other combination of the four parameters) ???
Nothing is complicated about that. What I was looking for was a way to
leave alone a program that has:
move 'mysubr' to subroutine
call subroutine using p1 p2 p3
when program 'mysubr' has been change to support a fourth parameter, ie:
procedure division using parm1 parm2 parm3 parm4
Say there are 20 programs that call 'mysubr'. Only two of them care about
this new, fourth, parameter. The only reason that the other 18 programs
need to be touched is because they need to pass to the new version of
mysubr
a data area to hold data which they don't even care about.
I hope you don't think I made this problem up just for fun. I had an
actually case a few years ago when this would have been useful. Of course
we lived without it.
Frank
A large amount of the maintenance that goes on in COBOL shops is down to
interface changes, exactly as you describe.
In an OOP environment the same kind of problem can happen, but the
environment is more "forgiving"...
I'll try and explain.
Suppose I have a Class and it has a method called "SomeMethod" that takes
parameters p1, p2 and p3.
I get an object instance of this class stored in "objMyClass" (OBJECT
REFERENCE)...
In OO COBOL I would write:
invoke objMyClass "SomeMethod"
using p1, p2, p3
end-invoke
Now we hit a snag. My Class can be late or early bound. If it is late bound
things are resolved at run time and I can "get away with" not passing all
parameters to it; if it is early bound, the compiler will check the
parameters for compliance to the method prototype and shoot me down in
flames if they are not "all present and accounted for".
I use latebound classes exclusively because they require less maintenance
and are more flexible, but I have the luxury of deciding policy in my shop.
(Latebound does incur an overhead, but I find this acceptable... it is
simlar to, though not exactly the same as... dynamic versus static linkage.)
Some time back I got to thinking about all the regression testing every time
you change an interface and decided there had to be a better way.
There is. (at least if you are using OO COBOL).
Suppose there WAS NO INTERFACE? What if I could somehow set the parameters I
needed to use in the called method BEFORE I invoked it?
I know of no way to do this in standard COBOL, but there is a pretty easy
way to do it with OO, especially if the Class you are dealing with is a COM
object...
Say I only need p2 for a specific invoke... I can do this:
invoke objMyClass "SET-p2"
using ws-p2
end-invoke
(This uses the COM support base class in Fujitsu... here's the same thing in
a non-COM object)
invoke objMyClass "setp2"
using ws-p2
end-invoke
(The difference is that I don't have to write the "setter" method for the
COM object (they are inherited automatically from the Fujitsu Base Class), I
do have to if it is my own object.)
So now I have set the parameter(s) to whatever value(s) I want BEFORE
invoking the Class Method. I don't need to pass them and the interface
disappears...
invoke objMyClass "SomeMethod"
end-invoke
No interface, no regression testing.
If I add another parameter to the Class (and usually I don't, but that's
another story...) ONLY the calls that need THAT parameter need to be tested.
Object methods are encapsulated within the Class so there is no danger of a
new parameter affecting existing Methods. (I can make sure by simply
extending the Class or overriding it for instances where the new parameter
is used; existing instances use the same method with the same parameters
they have always used.)
It's fairly hard to explain the ramifications and benefits of this. I have
tried (and failed dismally... :-)) to do so here on a few occasions. This is
what I'm talking about when I say that OO requires less maintenance than
procedural code.
The "parameters" are set in the Class as PUBLIC PROPERTIES so they are
visible to external programs, through the GET and SET methods.
Calling (invoking, in an OO context) programs pre-set the "parameters"
before they activate the method. It's a bit like setting the points on a
railway line, then allowing the train to go.
Immediate benefits are encapsulation of specific methods and parameters, and
NOT needing to amend a suite of programs because an interface changed. If
there is no interface, it CAN'T change.
Pete.
--
"I used to write COBOL...now I can do anything."
.
- References:
- CALL using OMITTED
- From: Frank Swarbrick
- Re: CALL using OMITTED
- From: James J. Gavan
- Re: CALL using OMITTED
- From: Frank Swarbrick
- CALL using OMITTED
- Prev by Date: Re: Here's one problem
- Next by Date: Re: Here's one problem
- Previous by thread: Re: CALL using OMITTED
- Next by thread: Re: CALL using OMITTED
- Index(es):
Relevant Pages
|
