Re: Inheritance - Mailing list pgsql-hackers

On Fri, 2002-09-06 at 11:05, cbbrowne@cbbrowne.com wrote:
> Oops! greg@CopelandConsulting.Net (Greg Copeland) was seen spray-painting on a wall:
> >> That's a pretty forcible "constraint."  :-).
> >>=20
>
> Is there something broken with your mailer?  It's reformatting quotes
> rather horribly...

Hmm...not that I know off.  Never had complaints before anyways.  Looks
like an issue with MIME contents...perhaps your mailer doesn't properly
parse some MIME and/or mine is hosing it some how.  Not really sure.

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

You can complain about and redefine the model to suit your needs all day
long and get no where.  It doesn't change the need for it.  Fact is, it
would be nice to allow.  Fact is, OO-implementations tend to allow
this.  I'm quite happy to let you go to every OO computer language camp
and inform them that they've done it all wrong.  ;)

Citing that a specific example is all wrong hardly invalidates the
concept.  Since we are pretty much at the conceptual stage, I welcome a
conceptual argument on why this is bad and should never be done.
Please, be high level and generic.  After all, I too can give you a
hundred specific reasons why a cat is not dog (i.e. bad model)...but it
does nothing to facilitate the topic at hand.

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

Because this is how the real world works.  Often there are exceptions to
the rules.  When these rules differ, I've not seen a valid high level
conceptual reason that should prevent it.

Example:

animalquadruped (has 4-trunk limbs)    dog    injuredDog (has 0 or more trunk limbs)

Hopefully we can agree that a dog is still a dog even if it only has
three legs?  Hopefully you'll realize this was given to illustrate an
example and to prove a point.  Sometimes a model needs to allow for
exceptions to the rule.  You can argue that a three-legged dog is no
longer a quadruped but I prefer to believe that it is a quadruped which
just happens to be an exception to the rule.
>
> It may well be that they _aren't_ related as "parent/child."  They may
> merely be "cousins," sharing some common ancestors.

Yes, it's true.  Sometimes the wrong model is applied but that hardly
invalidates the concept or alleviates the need.

Regards,
Greg Copeland