Re: Inheritance

On Thu, 5 Sep 2002, Jeff Davis wrote:

> But a person is-a employee (allow me to momentarily step aside from
> the rules of english grammer, if you would), and a person is-a
> programmer. That's why I didn't call my table "job" :) [1]

Certainly it's not the case that a person is-a job, by virtue of the
fact that a person can have no job. Nor is it the case that a person
is-a programmer; not all people are programmers.

Perhaps you're reversing the sense of "is-a"? One says "subtype is-a
supertype," not "supertype is-a subtype."

But even reversing these, it's not the case that job is-a person, by
virtue of the fact that you cannot use a job anywhere you can use a
person. (A person can file his tax return, a job can't.) That might be a
matter of bad mappings of object names to real-world concepts, though.

As for "programmer is-a person," yes, you could model things that way if
you really wanted to. But it's a bad way to do it because, as you point
out, a person can change his job, or not have a job. Now what do you do
with that programmer-subtype-of-person object you created? I think in
this case English misled you: we do say that "he is a programmer," but
what we really mean is that "one of the characteristics of that person
is that he programs." So create a separate characteristic type and have
the person object "have-a" as many or as few of those characteristics as
you need.

> I don't like the way some OO programming languages handle objects, if they
> mean to say you can't change an object's type without performing a logical
> data copy to a new object.

That's not a problem with the programming language; that's you
modelling things badly.

> Take as an example python... it's easy to emulate other objects: just assign
> to the attribute, even if it's not there yet, it'll add the attribute. Same
> with python, it's providing room to expand for it's objects already, so why
> do all the copying? Now compare with Java, and see why you'd be annoyed. It
> has the facilities to change the objects all around, but you can't do it.

Yes, you can't do it in Java because you Can't Do It in a language where
you can specify static typing. If I have field that holds a String, I'm
given a guarantee that, if I can put a reference in that field, it is
and always will be a String.

In non-statically-typed languages that give you the option of changing
types, you might give a referenc to a string, change the objects type on
me, and then I might blow up when I try to use it later. These bugs tend
to be quite difficult to track down because the source and manifestation
of the problem can be widely separated in code and in time. That's why
most languages don't allow this.

> ...when the more obvious logical path is to expand on the data you
> already carry about an entity.

Yes, that's the perfectly obvious path. And that's just what the
relational model lets us do, and do very well.

Why do you want to use an ill-fitting, error-prone model when you've
already got something that works better?

> [1] Come to think of it, the JOIN operator seems to, at least on a first
> thought, represent the "has-a" relationship you describe.

You bet! Hey, this relational stuff doesn't suck so badly after
all, does it? Especially for a 30-year old theory. :-)

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC