[program-l] subprograms was ...Re: Thinking About Objects Again
- From: "R Dinger" <rrdinger@xxxxxxxxxx>
- To: <program-l@xxxxxxxxxxxxx>
- Date: Thu, 4 Oct 2012 18:25:42 -0700
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.
Other related posts:
