[program-l] Re: subprograms was ...Re: Thinking About Objects Again
- From: Jim <jhomme1028@xxxxxxxxx>
- To: program-l@xxxxxxxxxxxxx
- Date: Thu, 4 Oct 2012 21:34:56 -0400
Hi Richard,
I'm really reaching for memories of how this worked. I think I
remember that the main program had something called the Linkage
Section, in which the programmer would define the data the main
program would use from the sub program. The thing I don't remember,
though, is how the code in the Procedure Division of the main program
referenced the Procedure Division of the sub program. One thing I
absolutely do remember, though, was that all of this was a real big
pain, because we had to have all kinds of naming conventions to make
sure there were no name colisions between the data items and the
procedures, because everything was either a global variable or a
global procedure. And we thought nothing of all of that. My little
exposure to objects has me loving that you have to make as many things
as possible local, or you have to name them with dot notation to force
the program to do the right thing.
Maybe this will come together for me this time.
Jim
On 10/4/12, R Dinger <rrdinger@xxxxxxxxxx> wrote:
> Hi Jim,
>
> I have been thinking about your subprogram example in Cobol. I know a
> little Cobol, but have never actually worked in it, and I think from my
> perspective that you are exactly right. Subprograms are just like objects
> in many ways. They both have private data and some internal procedures to
> process that data.
>
> Now days Cobol programmers probably use objects to do the same things. I
> suspect the subprograms you saw were required because of internal memory
> restrictions on computers years ago. A subprogram could be swapped in and
> out of memory quickly in a large system
>
> Richard
>
> ----- Original Message -----
> From: Homme, James
> To: program-l@xxxxxxxxxxxxx
> Sent: Wednesday, October 03, 2012 8:49 AM
> Subject: [program-l] Thinking About Objects Again
>
>
> Hi Richard, and who ever else wants to chime in,
>
> I feel like you were talking to me about objects, because I seem to have a
> hang up about them. When you said what you did, I thought about Cobol sub
> programs. This was before Cobol had objects. I think it has them now.
> Anyway, a sub program was self contained. It had its own data and
> procedures. Where I work, we used to have sub programs that would perform
> limited functions, like if the main programs in the system we worked on
> wanted to use a certain file and go after that data, they wouldn't have the
> code for that all scattered throughout dozens of programs. They'd put it in
> a sub program and just use it. That's not exactly what happened. I'm
> simplifying the example to make a point. I'm pretty sure that we didn't have
> the notion of sub programs that used sub programs, but I would think that we
> could have built the system that way.
>
>
>
> So when I start to think about Python, I'm getting used to the idea that in
> stead of a function being part of the Python language, it's actually part of
> a list. And the list can do things to itself, like add members and delete
> them. That's probably a bad example, because I don't have a Python reference
> right in front of me. And when you query if something is in this list,
> behind the scenes, somehow, Python is running the code in the list object
> and maybe getting some sort of return code, or true/false something that
> tells it that yes, there is this thing in the list that you are looking
> for.
>
>
>
> Another thing that seems to keep me from understanding some of this stuff is
> that people will write their descriptions in code before they explain it in
> words, but maybe that's just my learning style.
>
>
>
> One thing I don't understand at all, so far, and I've read this, is that
> they say that everything in Python is an object. So I'm really having
> trouble wrapping my brain around how something can look like a keyword or
> function call when I code it, and actually be a method, because when I start
> to read about how to write code for classes, the code looks different, so I
> feel kind of wierded out. I want to ask myself "Why don't we either code as
> though everything is made up of objects with dot notation, or simply not use
> dot notation, or both, so we can keep it all straight?" I'm sure that I'm
> totally missing something here with my thinking. But it feels better to
> attempt to talk about it.
>
>
>
> I hope that made some sort of sense.
>
>
>
> Thanks.
>
>
>
> Jim
>
>
>
>
>
>
>
>
>
>
> --------------------------------------------------------------------------------
>
> This e-mail and any attachments to it are confidential and are intended
> solely for use of the individual or entity to whom they are addressed. If
> you have received this e-mail in error, please notify the sender immediately
> and then delete it. If you are not the intended recipient, you must not
> keep, use, disclose, copy or distribute this e-mail without the author's
> prior permission. The views expressed in this e-mail message do not
> necessarily represent the views of Highmark Inc., its subsidiaries, or
> affiliates.
>
--
e+r=o
Skype: jim.homme
** To leave the list, click on the immediately-following link:-
** [mailto:program-l-request@xxxxxxxxxxxxx?subject=unsubscribe]
** If this link doesn't work then send a message to:
** program-l-request@xxxxxxxxxxxxx
** and in the Subject line type
** unsubscribe
** For other list commands such as vacation mode, click on the
** immediately-following link:-
** [mailto:program-l-request@xxxxxxxxxxxxx?subject=faq]
** or send a message, to
** program-l-request@xxxxxxxxxxxxx with the Subject:- faq
Other related posts:
