Re: CALL using OMITTED
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 1 Oct 2008 00:07:14 +1300
"James J. Gavan" <jgavandeletethis@xxxxxxx> wrote in message
news:ihhEk.97$cs4.78@xxxxxxxxxxxxxxx
Frank Swarbrick wrote:<snip>
On 9/26/2008 at 8:43 PM, in message <p5hDk.137$J63.102@xxxxxxxxxxxx>,
James
J. Gavan<jgavandeletethis@xxxxxxx> wrote:
I thought your idea of using collections for parameters was imaginative, but
there are a couple of problems with it, as far as I'm concerned.
1. Encapsulation. An object instance of a Class should be encapsulated.
PROPERTIES achieve that, sharing parameters in a Collection, doesn't. It
becomes unwieldy when you start having a separate Collection for each
program, although you certainly COULD do that. The problem is that the
Collection has to be shared so that whatever is calling can set it up. That
violates encapsulation. Using the PROPERTY approach, only the object which
owns the property can ever access it. "Outsiders" have to do so through a
method of the object.
2. There are a variety of ways to access the collection (indexes, keys,
hashes, etc.) and this gets confusing. The access method needs to be
overridden if you want to access with a key to a parameter instead of an
index. If you manage it with collection indexes they have to be maintained
when a parameter is deleted, and so on. It is DOable, but unwieldy in my
opinion. (You may not be aware, but Fujitsu (at Enterprise level) offer a
rich series of Collection Classes for COBOL. They include:
COLLECTION CLASS
CLEAR-COLLECTION Makes the current collection empty.
CLONE-COLLECTION Creates a replica of the current collection.
CONTAINS-ELEMENT Checks whether the current collection contains a specified
element.
CONTAINS-ALL-ELEMENT Checks whether the current collection contains all
elements in
a specified collection.
CREATE-ITERATOR Creates an iterator object for the current object.
GET-SIZE Returns the number of elements in the current collection.
IS-EMPTY Checks whether the current collection is empty
LIST CLASS
CREATE-LIST-ITERATOR Creates a list iterator object for the current list.
EQUALS-LIST-COLLECTION Checks whether the current list matches a specified
one.
LINKED LIST CLASS
ADD-FIRST-ELEMENT Adds an element to the head of the current list.
ADD-LAST-ELEMENT Adds an element to the end of the current list.
GET-FIRST-ELEMENT Returns an element at the head of the current list.
GET-LAST-ELEMENT Returns an element at the end of the current list.
REMOVE-FIRST-ELEMENT Deletes an element at the head of the current list.
REMOVE-LAST-ELEMENT Deletes an element at the end of the current list.
SET CLASS
ADD-ELEMENT Adds an element to the current set.
ADD-ALL-ELEMENT Adds all the elements included in a specified
collection to the current set.
EQUALS-SET-COLLECTION Checks whether the current set and a specified set
are equivalent.
REMOVE-ELEMENT Removes an element from the current set.
REMOVE-ALL-ELEMENT Removes all the elements included in a specified
collection from the current set.
MAP CLASS
CLEAR-COLLECTION Makes the current map empty.
CLONE-COLLECTION Creates a replica of the current map.
CREATE-ITERATOR Creates an iterator object for the current map.
GET-SIZE Returns the number of entries for the current map.
IS-EMPTY Checks whether the current map is empty.
MAP ENTRY CLASS
CONTAINS-KEY Checks whether a specified key is contained in the
current map.
CONTAINS-VALUE Checks whether a specified value (object) is
contained in the current map.
EQUALS-MAP-COLLECTION Checks whether the current map matches a
specified map.
GET-VALUE Returns a value (object) of a specified key from
the current map.
PUT-ENTRY Adds an entry (key and value) to the current map.
PUT-ALL-ENTRY Adds all entries (keys and values) contained in a
specified map to the current map.
REMOVE-ENTRY Deletes an entry (key and value) of a specified key
from the current map.
COLLECTION EXCEPTION CLASS
GET-CLASS-NAME Returns the class name of a class library in which an
exception object occurs.
GET-METHOD-NAME Returns the method name of a class library in which an
exception object occurs.
GET-CODE Returns an exception type.
GET-MESSAGE Returns an exception message
I have never had occasion to use them in COBOL, but I use collections in C#
and VB all the time. I think it is fair to consider a set of parameters to a
program as a collection. It is the mechanics of it, not the concept which I
don't personally like.
..
Pete's sentence :-
"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?"
May not be the answer to his question, but if he was to :-
invoke Program2 "new" using Collection2 returning Obj-Program2
I normally don't have a "new" method in FACTORY letting the caller program
do its thing by referencing Class Base at the top of the hierarchy.
*>-------------
FACTORY
method "new".
Linkage.
01 lnk-Collection object reference.
01 Lnk-self object reference *> = Instance of Program2
Procedure Division using Collection returning lnk-self
.
Invoke self 'new' returning lnk-self
invoke lnk-self "initialize" using lnk-Collection
*>------------------------
OBJECT.
WORKING-STORAGE SECTION.
78 ExpectedSize value 4.
01 ParameterTable.
05 Param1 pic 9(03). *> makes sense to call each parameter
05 Param2 pic x(128). *> by its original number in the
05 Param3 pic 9(05). *> CALLing program to avoid confusion
05 Param4 pic x(22).
01 ws-size pic x(04) comp-5.
method "initialize"
Linkage.
01 lnk-Collection
Procedure Div using....
invoke lnk-Collection "size" returning ws-size
if ws-size <> ExpectedSize ... we have a problem.....
perform varying n from 1 by 1 until n > ws-size
move function-length (n) to Param1 etc.....
end-perform
*** I'm really free-wheeling above without the compiler - but hopefully it
conveys the idea.
I see what you are saying, but I wouldn't do it. (Too complex...)
I think you can see the germ of an idea. OO is infinitely flexible and you
have received two different approaches. I don't think you can get your lot
into dotNet, (could be very wrong on that because I haven't studied the
topic), but push your guys for Java as an alternative.
Off the wall idea for Procedural COBOL - could you have a separate program
to establish the parameters per called program and perhaps use the
entry-point technique ???? No clear ideas, but just a thought.
The problem is that parameters need to be associated with a Class, and
different methods of the Class may require different parameters. I use
Object PROPERTIES because they are owned and accessed by the Class, and
access to them is simple and unambiguous.
Connecting a group of parameters on a file or database (or in a
Collection...) and then using different entry points to access them is
technically feasible, but I have never worked on a site where they would
allow this.
I think it is an imaginative approach but it is just too complex and
unwieldy, compared to using properties.
Just one man's opinion...:-)
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
- Re: CALL using OMITTED
- From: James J. Gavan
- CALL using OMITTED
- Prev by Date: Re: Flowchart of Cobol code
- Next by Date: Re: Flowchart of Cobol code
- Previous by thread: Re: CALL using OMITTED
- Next by thread: date processing in z/OS
- Index(es):
Relevant Pages
|
