From: "change kom to com" <benr@netcom.kom>
Newsgroups: alt.humor.best-of-usenet
Subject: [comp.databases.pick] Re: I give up! Is a subroutine an object?
Date: 21 Dec 1997 19:19:06 GMT

Subject: Re: I give up! Is a subroutine an object?
From: luke@oberon.sub.net.au (Luke Webber)
Newsgroups: comp.databases.pick

"Bill H." <wphaskett@worldnet.att.net> writes:
> Bob Dubery wrote that he's "struggling with this..."
[snip]
> I'd hate to think that each segment of technology has decided
> to redefine many previously useful, and perfectly
> descriptive, words to mean completely different and
> conflicting things.  Kind of like 'tar', 'grep', 'awk', etc.
> Yea, I know they mean something, but I'd hate to ask someone
> to tar my data and find out tomorrow that our computer is
> black and sticky and has feathers stuck to it.

Well jargon isn't a single edged tool. If I say "attribute", an
RDBMS person says "Huh? Oh, you mean COLUMN", and a flat-filer
says "field".  You say Item, they say row or record.  Trouble
is, "object" is an overused word which has been hijacked into
the realms of computer science, there to be dissected and
disputed until it dies of embarrassment.

> For instance, my experience tells me that an "object" is
> something solid that I can touch or feel (yea, yea, like my
> nose), or the subject of some action in a sentence, such as
> "those programmers are snickering at 'him'".

> Ok, so is an 'object' anything?  I've been told as much. But
> this is a pitifully non-descriptive description.  Or is an
> 'object' a representation, on a computer, of a 'real' object,
> or some other representation of a 'real' object such as a
> picture, text, sound, etc?  Under this definition, an object
> becomes an abstraction.  But this is what we expect of a
> 'representation'.  Does an object include any tool used to
> manipulate these 'representations' such as programs,
> methodologies, etc?  My understanding and experience with
> English is killing me with regard to these techno-concepts.

Your nose is indeed an object, and it's a descendant of the
general class of noses, except that it's a fine, big, red one
with a wart on the tip, sprouting many sturdy hairs. How big,
what shade of red, how many hairs and how long?  These are all
questions which we have to apply to the very specific instance
of *your* nose.  Your brother's nose is descended from the same
class, but it is slightly less hairy and has *three* warts, and
added grease. <g>

OK, I'm getting silly. Basically, an object is a specific
instance of a class of thing, with its own peculiar properties.
One Winblows text box might be bigger than another, and hold
different data, but they're both text boxes (or edit controls
really, but that's another matter <g>), and everything that
happens to them goes through the same code, which belongs to the
general class of text boxes.

Now, if I decide to create a subclass of the text box which
only accepts numeric input, it is *still* a textbox, but with an
added feature.  If I use three of my new textboxes and ten of
the normal kind in a program, I have thirteen sets of whatever
data a textbox needs, plus three copies of any data I might
have added to my new class, plus one copy of the code associated
with a textbox, plus one copy of the code I added for my numeric
text box. Whoopee!

> I've read many places that "...Objects inherit properties
> from their parents..."  What in the world does this mean?
> Were 'objects' poor and are now rich?  Do 'objects' pay taxes
> on their properties?  What happens if their parents aren't
> loving and decide to leave their property to a charitable
> institution instead?  Ok, enough levity.

MyArticle.Levity := False; // Well, not really.

> What is an 'instance'?  I've always thought it was a "...case
> or an example of some thing...", like I'm an instance of
> someone who is having a hard time understanding these
> redefinitions to describe redefined concepts that, somehow,
> we're all familiar with.

Like on a Winblows data entry form, when you see ten edit
controls, two combo boxes and five radio buttons. They each have
a known state and other data, but there is only one copy of the
code that determines their behavior.  Of course, some of their
behavior is defined by the properties of the object itself, but
only because the code is aware of said properties and acts
accordingly.

Well that's about as clear as mud.  Oh for Henry's clarity of
expression!

> Now, I understand a subroutine being called.  I understand
> that information needs to be passed to the subroutine from a
> 'calling' program in a certain order and within certain
> containers usually described as variables.  I also understand
> that the subroutine expects to receive a certain amount of
> information, in the form of variables, although we can pack
> even more information within these variables from time to
> time.  This doesn't seem much like an 'object'.  I seems much
> more like a way to get something done, specifically on the
> data in a database, although it could be used to initiate some
> process, like a communication connection, or a data transfer,
> etc.  Is an object both the 'data' and the 'process'?

Suppose you had one copy of the same subroutine, and this
subroutine had a static data area of its own, a *bit* like named
common.  Now you load a whole new copy of this s/r, with new
data areas, but the logic is shared, with no added memory
overhead. Of course, if another user is using the same s/r, you
still have no additional code overhead.

So you might have one "object" which accepts and stores
free-form data, plus another which does the same, but only
allows valid dates, plus another which only accepts numbers, and
yet another which accepts numbers, but also has a couple of
arrow buttons to scroll those numbers back and forth...

But now we're straying into inheritance, because the smart OO
programmer wouldn't handle this behavior by setting properties
of our theoretical class.  Instead, he'd create one class which
accepted just about anything, then he'd create "descendants" of
that class which had other capabilities and peculiarities.

> Clearly, it makes sense to build small segments of code, that
> can be reused, or can be used to build a completely new
> application.  However, how complicated do we need to get to do
> the simplest task?  Is this encapsulation?

Encapsulation is more in the nature of the privacy of data.
Let's say you labour mightily and define a class called "Offspring".
Its descendant objects have certain behaviors which are common
to all offspring, including a complex and sometimes competitive
relationship.  This demands that each instance of the class
Offspring be provided with its own instance of the classes
"Room", "Allowance", "QualityTime", and before you know it
"CarKeys".  Those things are encapsulated, because your
"Offspring" keep them to themselves, but they are also exposed
through certain methods such as PayAllowance, MoreQualityTime,
TidyRoom, GiveCarKeys.  Of course, there is no such method as
"GrabAllowance", because the class deems this to be an
unacceptable type of access.

There is data that is kept even more private than this. For
example, the DopeCache and DirtyMagazine variables are not seen
at all, except by the Offspring's friend classes. (Not all
languages support friend classes.  For example, the Java
Offspring implementation is totally alienated and particularly
suicide-prone).

> What is inheritance?  Is is information that is passed?  Or
> is it information that some process simply knows through
> osmosis?  Where does it get it from?  How does it get it?
> It's got to get it from somewhere.  Does a larger process
> 'give the information' to a smaller process?  Is this where
> the 'parent' concept comes from?  Is this why the passing of
> data from a Basic main program to a Subroutine could be
> described as 'inheritance'?  Although I seem to hear that this
> is not true in the strictest sense!

OK, the class of Offspring needs at the very least two
descendant classes, call them "Son" and "Daughter".  Don't get
me wrong, these guys don't inherit *anything* from _you_.
Except maybe your house, your money, your booze, your car, you,
and your capacious free time.  Still, Son and Daughter inherit
*everything* from the class Offspring, including the crooked
teeth and the drug habit.  OTOH, "Daughter" is not fitted with
the "DeepVoice" option, which becomes active in "Son" several
months after the "SqueakyVoice" and "EmbarrassingTrouserLump"
properties manifest themselves.

Instead of these, the "Daughter" class always has the
properties "Breasts", which can be either "TooLate",
"TooEarly", "TooSmall", "TooLarge" (rare), "Lumpy", "Floppy" or
"Perfect" (extremely rare).  This class also suffers from a
resource leak which leads them to occupy large amounts of
bathroom time and their father's (no relation, remember)
attention.

> I hope to hear an excellent description in 'real' terms
> instead of in new-age techno-speak terms where the definitions
> are used to describe concepts that in turn define the
> definitions.

I trust that's all clear now. ;^)