Re: Inheritance - Mailing list pgsql-hackers

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