Re: Inheritance

On Mon, 2002-08-19 at 09:42, Curt Sampson wrote:
> On Mon, 19 Aug 2002, Zeugswetter Andreas SB SD wrote:
>
> > > So what you're saying is that constraints shouldn't be inherited?
> >
> > No. I even said that inheriting should be the default.
>
> Ah. So you think it should be possible not to inherit constraints.

I've been silent for a bit because I wanted to kick the concept around
in my head. After some thought, I say that I support children
inheriting constraints. In a more abstract sense, we are really setting
conditions for all entities of a given type (class) which must be met to
classify as a defined type. Again, in an abstract sense, if I say all
"candies" (type/class, candy) must have sugar (constraint), and I go on
to create a subclass of candy which I desire not to have sugar, then
there is a fundamental problem. Either I incorrectly identified my
problem domain and didn't properly create my entities which address my
domain needs or what I'm trying to express really isn't a candy at all.
In other words, it sounds like candy should of been a subclass of a more
abstract base entity. Likewise, the newly desired class which doesn't
have sugar should also inherit from the newly created base class and not
be derived from candy at all.

>
> > A local constraint should be made obvious from looking at the schema,
>
> Ok, this now I could live with. Though I'm not sure that its
> theoretically very defensible, or worth the effort. Other languages
> that offer constraints, such as Eiffel (and soon Java), do not allow
> constraints that are not inherited, as far as I know. Do you have some
> counterexamples.

I tend to agree. Constraints should be inherited. See above.

>
> > Well, that is where I do not think this is flexible enough, and keep in mind
> > that all triggers and rules would then also need such restrictions.
>
> Yes, all triggers, rules, and everything else would have to be inherited.

Agreed.

>
> > Regardless whether your objection is *strong* or not :-)
> > If you don't like the feature (to add a local constraint), don't use it.
> > (Remember you are talking about removing an implemented feature)
>
> 1. It's not exactly an implemented feature, it's an accident of an
> incomplete implementation of inheritance done in a certain way.
>
> 2. Should we change the way we decide to implement inheritance,
> perhaps to make fixing the current problems much easier, it might
> be a lot of work to add this.
>

I'm still trying to figure out if subclasses should be allowed to have
localized constraints. I tend to think yes even though it's certainly
possible to create seemingly illogical/incompatible/conflicting
constraints with parent classes. Then again, my gut feeling is, that's
more and an architectural/design issue rather than a fundamental issue
with the concept.

--Greg Copeland