Re: OOP real life example (was Re: Why is MySQL more

On Mon, 2002-08-12 at 00:29, Hannu Krosing wrote:
> On Mon, 2002-08-12 at 11:52, Curt Sampson wrote:
> > On Sun, 11 Aug 2002, Don Baccus wrote:
[snip]
> > But anyway, I have no particularly huge objection to syntatic sugar
> > alone. I do have objections to it when it's not saving much typing. (It
> > is in this case, but that could be fixed with better automatic support
> > of view updates.)
> >
> > But my real objection is when it makes things more confusing, rather
> > than less, which I think is definitely happening here.
>
> What makes things more confusing is poor understanding of a feature, not
> the feature itself.

Agreed. Just because a feature may not be well understood by the masses
doesn't mean the feature is worthless.

>
> > I've never
> > seen a rigourous explanation of our model of table inheritance,
> > nor any model that was more obviously correct than another. And
> > the parallel drawn with inheritance in OO languages is a false
> > parallel that adds to the confusion.
>
> Are you saying that inheritance in SQL is something fundamentally
> different than inheritance in OO languages ?
>

Hmmm...there might be. Curt raises in interesting point below. Do keep
in mind that I believe he's specifically referring to table inheritance
and not the broad scope of "language wide" inheritance.

> > (For example, the distinction
> > between types and instances of types is critical in OO theory. What are
> > the TI equivalants of this?)
>
> If by TI you mean type instance then the equivalent of of an instance is
> a relation (i.e. one row in an (inherited) table).
>

Look a little deeper here. In other OO implementations, I can define a
class (say class a) which has no instances (abstract base class).
Furthermore, I can take this case and use it for building blocks
(assuming multiple inheritance is allowed in this world) by combining
with other classes (z inherits from a, b, c; whereby classes a, b, c
still do not have an actual instance). I can create an instance of my
newly inherited class (z).

Seems to me that there is some distinction between types (classes) and
and type instances (instance of a specific class) as it pertains to it's
usability.

How exactly would you create an abstract base class for table type?

I'm still trying to put my brain around exactly what the implications
are here, but I *think* this is what curt was trying to stress. Curt,
feel free to correct me as needed.

> > All this is borne out by the regular questions one sees about
> > inheritance in the mailing lists. I'll admit a good part of it is
> > due to the broken implementation of inheritance, but all of the
> > problems I've ever seen are easily solved with very simple relational
> > solutions.
>
> All _simple_ inheritance problems are easily solved by simple relational
> solutions. The general problem of much more typing and debugging, less
> clues for optimiser etc. are not solved by _simple_ relational
> solutions.

I agree with Hannu here. Curt's comment seems like lip service. Worth
noting too, even if it were not for the issues pointed out by Hannu
here, Curt's statement certainly does nothing to invalidate the concept
of table inheritance. After all, most camps are happy when there are
multiple means to an end. Just because it can be done via method-x,
doesn't invalid method-y. The inverse is probably true too. ;)

>
> > Maybe the inheritance thing is causing people to turn off the relational
> > parts of their brain or something.
>
> Of maybe people are diversifying, using inheritance for is-a
> relationships and relational model for has-a relationships.

That's an interesting point.

Greg