Re: Inheritance

On Thu, 2002-09-05 at 12:29, Jeff Davis wrote:
> >
> > This is not so wrong. If you think about it, you have the same
> > problem in most object-oriented programming languages: a person
> > object can't generally easily become a subclass of itself after
> > being created.
> >
> > This is a case, I would say, where you simply don't want to use
> > inheritance. A person has-a job, not is-a job.
> >
>
> 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]
>
> 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. If you don't use some kind of extra layer of
> abstraction in C, you will end up with that problem: you'd need to copy all
> that RAM over to change from one struct to another. Most people would rather
> take that RAM copying hit than all the hits for allowing "room to expand" (at
> least in some applications). However, postgres needs to provide that "room to
> expand" for each tuple anyway, so to go through the same copying seems bad
> (especially since we're no longer just talking RAM).

I would like to have UPDATEs both up and down the inheritance hierarchy,
so that when I have hierarchy

OBJECT(id serial primary key)
+ HUMAN(name text,age int)
+ EMPLOYEE(salary numeric)
+ ENGINEER(workstation computer)
+ PHB(laptop computer)

and ENGINEER named Bob

I could do

UPDATE ENGINEER
TO PHB
SET salary = salary * 2 + age * 1000,
laptop.disksize = max(laptop.disksize ,
workstation.disksize + 1000000)
WHERE name='Bob'
;

to promote Bob from an engineer to phb, give him a salary rise and a
laptop with default configuration ensuring big enough disk to keep all
his old files, but still keep all FK related records.

> 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?

that's unless you use the new-style objects and __slots__

>>> class myobj(object):
... __slots__ = ['a','b']
...
>>> M = myobj()
>>> M.a =1
>>> M.c =1
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'myobj' object has no attribute 'c'
>>>

> Same with python, it's providing room to expand for it's objects already,
> so why do all the copying?

> [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 could have the
> tuples "manager" and "programmer" in the table "job" and join with a "people"
> table. Don't ask about inheritance yet for this model, I'm still thinking
> about that one (does "has-a" even have an analogue to inheriteance?).

Not in inheritance, but in OO world attributes are used to express has-a
relations. So

bob = people(name='Bob')
bob.job = job('Manager')

makes an has-a relation between Bob and his job in python

BTW, good programming guidelines in python tell you not to test if bob
is-a something but rather test if the interface for something exists -
to see if you can iterate over bob you do not test if bob is a sequence
but just try it:

try:
for idea in bob:
examine(idea)
except TypeError:
print 'Failed to iterate over %s %s !' % (bob,job.name, bob.name)

---------------
Hannu