Re: Mutually dependent private types

[John Volan <johnv@ac3i.dseg.ti.com>]

adam@irvine.com wrote:
> 

> IMHO, it still would be more ideal, and more in keeping with software
> engineering principles, if I were able to add new functionality to P1
> without touching P2.  Granted, we can't expect this to happen in every
> case, but if there are reasonable extensions to the language that
> would help in cases like this, I think they should be considered next
> time the language is enhanced.

Adam, the strategy Matt suggested -- sacrificing static strong type
checking in order to avoid mutual spec dependencies -- does NOT require
your two packages to be children of a common parent package.  Your two
types T1 and T2 can remain mutually private to each other, yet they can
still be derived from a common root type. That type can come from a
third package entirely unconnected to either package P1 or P2:

package Objects is
  type Object_Type is abstract tagged limited null record;
end Objects;

with Objects;
package P1 is
  type T1 is new Objects.Object_Type with private;

  procedure Op1 (O1 : in out T1; O2 : in Objects.Object_Type'Class);
  -- precondition: O2 in P2.T2'Class

  function Get_F (O1 : in T1) return Float;
private
  type T1 is new Objects.Object_Type with
    record
      F : Float;
    end record;
end P1;

with Objects;
package P2 is
  type T2 is new Objects.Object_Type with private;

  procedure Op2 (O2 : in out T2; O1 : in Objects.Object_Type'Class);
  -- precondition: O1 in P1.T1'Class

  function Get_I (O2 : in T2) return Integer;
private
  type T2 is new Objects.Object_Type with
    record
      I : Integer;
    end record;
end P2;

The only changes you have to make are (1) add the "with Objects;"
clauses; (2) add your new functionality (procedures Op1 and Op2); and
(3) change the declarations of types T1 and T2 so that they're derived
from the common root type (in this case, Objects.Object_Type), if they
weren't already derived from that before.  You don't have to change your
overall packaging scheme; P1 and P2 can stay P1 and P2.  All your other
code that was calling P1 and P2 can stay the same. You don't need to
play around with tricks like library-level renaming.  You do have to
recompile the universe, though, but that's not so big a deal.

> > I read John's paper, but I don't find his argument convincing.  Doesn't the
> > following code solve the putative with'ing "problem"?
> 
> I think John's objection to this solution is that it requires a
> runtime check to make sure the second parameter has the correct type.

Exactly.

> Also, one could object on philosophical grounds that requiring the two
> packages to be children of a common parent isn't appropriate for
> packages that really don't have much of a common purpose.

But they don't have to be children of a common parent after all, so this
philosophical quandary doesn't have to arise in this case.

> (Then
> again, I suppose that with every language there are cases that require
> one to write code that goes against software engineering philosophy.)

In any reasonably powerful/complex language, there's usually more than
one way to skin a cat. Some ways are easier and simpler than others.
With enough creativity and ingenuity, anyone can devise a Rube Goldberg
solution... ;-)

-- 
Signature volanSignature = 
  new Signature
  ( /*name:      */ "John G. Volan",
    /*employer:  */ "Raytheon Advanced C3I Systems, San Jose",
    /*workEmail: */ "johnv@ac3i.dseg.ti.com",
    /*homeEmail: */ "johnvolan@sprintmail.com",
    /*selfPlug:  */ "Sun Certified Java Programmer",
    /*twoCents:  */ "Java would be even cooler with Ada95's " +
                    "generics, enumerated types, function types, " +
                    "named parameter passing, etc...",
    /*disclaimer:*/ "These views not packaged in COM.ti.dseg.ac3i, " +
                    "so loading them throws DontQuoteMeError. :-)" );