Re: Inheritance - Mailing list pgsql-hackers

From Greg Copeland
Subject Re: Inheritance
Date
Msg-id 1031326047.18470.139.camel@mouse.copelandconsulting.net
Whole thread Raw
In response to Re: Inheritance  (cbbrowne@cbbrowne.com)
Responses Re: Inheritance  (elein <elein@norcov.com>)
List pgsql-hackers
On Fri, 2002-09-06 at 08:57, cbbrowne@cbbrowne.com wrote:
> > On Fri, 2002-09-06 at 07:37, Curt Sampson wrote:
> > > On 5 Sep 2002, Hannu Krosing wrote:
> >
> > To elaborate on Gregs example if you have table GOODS and under it a
> > table CAMPAIGN_GOODS then you may place a general overridable constraint
> > valid_prices on GOODS which checks that you dont sell cheaper than you
> > bought, but you still want sell CAMPAIGN_GOODS under aquiring price, so
> > you override the constraint for CAMPAIGN_GOODS.
>
> What that tells me is that the constraint, valid_prices, shouldn't have been
> on GOODS in the first place.  If it is not a legitimate constraint for the
> children, then it is not a legitimate constraint for the parent.
>

I don't agree with you on that point.  This concept is common to many
OO-implementations.  Unless you can come up with a powerful argument as
to why our "to-be" picture should never do this, I'm less than
convinced.

> In human inheritance, if you marry someone with "funny coloured skin," you
> don't get to choose that your children won't have "funny coloured skin."
> That's a pretty forcible "constraint."  :-).
>

Fine, but that only works for YOUR specific example.  In that example,
the color constraint should be non-virtual, meaning, the child should
not be able to change it.  On the other hand, if I replace "human" with
"metal product", hopefully I won't be stuck with gun metal gray for
every derived product.  Hopefully, somewhere along the lines, I'll be
able to override the parent's color constraint.

> > Or maybe it is better to just make the check function should be
> > dynamically dispatched, so the constraint will always hold, it just can
> > mean different things for different types.
>
> Or maybe if someone is doing an Object Oriented design, and making extensive
> use of inheritance, they'll need to apply constraints in a manner that allow
> them to be properly inherited.

The problem with that assumption is that there is normally nothing wrong
with having seemingly mutually exclusive sets of *business rules* for a
parent and child.

Greg


pgsql-hackers by date:

Previous
From: Olivier PRENANT
Date:
Subject: Re: PL/Perl?
Next
From: cbbrowne@cbbrowne.com
Date:
Subject: Re: Inheritance