Re: Inheritance

From: Greg Copeland <greg(at)CopelandConsulting(dot)Net>
To: cbbrowne(at)cbbrowne(dot)com
Cc: Hannu Krosing <hannu(at)tm(dot)ee>, Curt Sampson <cjs(at)cynic(dot)net>, PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Inheritance
Date: 2002-09-06 15:27:26
Message-ID: 1031326047.18470.139.camel@mouse.copelandconsulting.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2002-09-06 at 08:57, cbbrowne(at)cbbrowne(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message snpe 2002-09-06 15:53:48 Re: JDBC 7.3 dev (Java 2 SDK 1.4.0)
Previous Message snpe 2002-09-06 15:21:00 Re: JDBC 7.3 dev (Java 2 SDK 1.4.0)