Re: Inheritance - Mailing list pgsql-hackers

Oops! greg@CopelandConsulting.Net (Greg Copeland) was seen spray-painting on a wall:
> --=-eu74lKXry3SVx8eZ/qBD
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
> 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.

If the plan is for table CAMPAIGN_GOODS to virtually be a view on GOODS,
then I'd say it _is_ necessary.

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

Is there something broken with your mailer?  It's reformatting quotes
rather horribly...

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

That happens by _adding_ an additional characteristic, presumably that
of "what kind of paint the metal is covered with."  That doesn't
override the fundamental constraint that if it's a metal product,
there _will_ be metallic properties.

If you decide to add in some "non-metallic" products, then it would be
_silly_ to have them inherit all their characteristics from
"METAL_PRODUCTS;" they should head back up the class hierarchy and
inherit their basic characteristics from the _appropriate_ parent.

Reality, with the "GOODS/CAMPAIGN_GOODS" example, is that GOODS isn't
the appropriate parent class for CAMPAIGN_GOODS.  Both should be
inheriting the common characteristics from some common ancestor.  If
that is done, then there's nothing to "override."

>> > 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.
>>=20
>> Or maybe if someone is doing an Object Oriented design, and making extens=
> ive=20
>> use of inheritance, they'll need to apply constraints in a manner that al=
> low=20
>> 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.

If the rules are totally different, it begs the question of why they
_should_ be considered to be related in a "parent/child" relationship.

It may well be that they _aren't_ related as "parent/child."  They may
merely be "cousins," sharing some common ancestors.
-- 
(concatenate 'string "chris" "@cbbrowne.com")
http://cbbrowne.com/info/spreadsheets.html
"Note that if I can get you  to `su and say' something just by asking,
you have a very serious security problem on your system and you should
look into it."  -- Paul Vixie, vixie-cron 3.0.1 installation notes