Re: Mutually dependent private types

[Matthew Heaney <matthew_heaney@acm.org>]

John Volan <johnv@ac3i.dseg.ti.com> writes:

> Matt, in your original example, you had T1 and T2 (and T1_Rep and
> T2_Rep) all derive from a common Root type. That looks a lot like the
> idea of having a universal root type that everything derives from.  (My
> real objection to your example was that you declared T1_Rep and T2_Rep
> in a common *package*, which I thought was unnecessary.)

You are correct - I was wrong to do this is my original response.

Note that I declared T1_Rep and T2_Rep in the same package because I
thought Adam required that each type have visibility to the other type's
representation.  If that wasn't the case, then I agree with you that
it's better to move each "forward" type into its own package.

> As you point out yourself, this spurious
> polymorphism creates an opportunity where someone could try (either
> accidentally or maliciously) to provide more than one full type for the
> same "forward" type.

Yes, but let's talk about reality.  While it's _theoretically_ possible
for a programmer to wrongly inherit from a forward type, in practice
it'll never happen.

package Employee_Forward is

   type ONLY_EMPLOYEE_BETTER_INHERIT_FROM_THIS is
      abstract new Person_Type with null record;

end;


> Furthermore, what if you're already using inheritance to support true
> polymorphism, and then you discover you need to break a mutual
> dependency somewhere in your class hierarchy?  You might end up with a
> situation I call "inheritance collision": That's where you're trying to
> apply Ada's inheritance mechanism for two competing purposes, but you're
> faced with the fact that Ada only supports single inheritance.  Sure,
> it's possible to wiggle your inheritance hierarchy around so that it'll
> work and you can still keep your mutually-dependent types in different
> packages. But I find that to be awkward and artificial.

If you have deep or otherwise "complex" type hierarchies in Ada, then
you're doing something wrong.  Hierarchies should be shallow.

When I hear stories about problems someone is having with their
inheritance hierarchies, I become suspicious, because it often indicates
that the programmer is fighting the langauge.

The "proper" style of object oriented design advocated in popular books
and journals mostly does NOT apply to Ada 95.  Much of the advice out
there (especially wrt inheritance) applies only to languages in which
the size of the object is known up front (ie the type has reference
semantics, and therefore it's just an address).

This is not the case for Ada, because types in Ada have value semantics,
and so their size isn't known up front.  This makes a type low in the
hierarchy _extremely_sensitive_ to perturbations of ancestor types.

As I explained in a post to cla a few months back, this seemingly
innocuous detail has overarching consequences for the design of software
systems written using Ada.  Very few Ada programmers really understand
this, and they often have "problems" with their inheritance hierarchies,
compilation depencies, etc, etc.

(A friend mine who came from a C background noted that you can always
tell who the Ada programmers are, because "they're the ones reading a
newspaper at their terminal."  He was observing that Ada programmers
often have to wait a long time for their compiles to finish - a sure
sign of design problem.)

> Bottom line, I don't think anyone can legitimately claim that Ada95
> offers a solution to mutual dependency problems "right out of the box". 
> All you can say is that there are various workarounds, with varying
> degrees of awkwardness, that can be used to make up for a fundamental
> hole in the language.

I'm not disagreeing that "workarounds" are required, but I feel this
whole "with'ing problem" has been blown way, way out of proportion.

The technique described in Norm's book is very simple, and doesn't
_in_practice_ compromise type safety.

> But a simple case
> of mutual dependency shouldn't call for polymorphism.

I'm not disagreeing, but what are you going to do?  This is the language
we've got _today_, so accept it.  If it bothers you that much, then turn
the tag check off!

> Depends on the style of software design you're using, which depends a
> lot on your programming culture.

I'm talking about Ada 95.  That there are design idioms specific to Ada,
and that one has to actually go out and learn these idioms, doesn't
bother me.

If your inheritance hierarchies are causing you problems, then it's a
sign that maybe your design is not suitable for implementation in Ada.
I'm a firm believer in designing _to_ the language.

I'm not disagreeing that, because you can't have mutual dependencies in
Ada, that this can cause an unnatural mapping to a language (as Java)
that does allow mutual depencency.  And I'm not disagreeing that this is
a Bad Thing, especially since Ada is advertised as "easily" interfacing
to other languages.  But this "withing problem" is just not that big a
deal.

Matt