From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 1108a1,23cd1575a227bc41
X-Google-Attributes: gid1108a1,public
X-Google-Thread: 103376,23cd1575a227bc41
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-10-11 16:55:25 PST
Path: 
 bga.com!news.sprintlink.net!howland.reston.ans.net!pipex!uunet!newsgate.watson.ibm.com!watnews.watson.ibm.com!ncohen
From: ncohen@watson.ibm.com (Norman H. Cohen)
Newsgroups: comp.lang.ada,comp.object
Subject: Re: Decoupled Mutual Recursion Challenger [Was: Mut. Recurs. in Ada9X
 w/o Breaking Encaps.? (LONG)]
Date: 11 Oct 1994 13:58:30 GMT
Organization: IBM T.J. Watson Research Center
Distribution: world
Message-ID: <37e5m6$oh0@watnews1.watson.ibm.com>
References: <1994Oct7.130100.26953@swlvx2.msd.ray.com>
Reply-To: ncohen@watson.ibm.com
NNTP-Posting-Host: rios8.watson.ibm.com
Keywords: Ada 9X, object-oriented, decoupled mutual recursion,
 "withing" proble
Xref: bga.com comp.lang.ada:6790 comp.object:7263
Date: 1994-10-11T13:58:30+00:00
List-Id: <comp.lang.ada>

In article <1994Oct7.130100.26953@swlvx2.msd.ray.com>, jgv@swl.msd.ray.com
(John Volan) writes: 

|> So far on this thread, all the solutions to the "withing" problem
|> (decoupled mutual recursion in Ada9x) share one common feature: They
|> have all used type derivation and inheritance to support the
|> distinction between "opaque" and "transparent" object identities, with
|> the translation between them being handled by safe downcasting
|> ("narrowing") and safe upcasting ("widening"?).
...
|>
|> The trouble with solutions that exploit inheritance is that they use
|> it solely as a mechanism for decoupling, without (as Adam Beneschan
|> pointed out) correlating it to any true generalization/specialization
|> relationship present within the problem domain.  It can be argued that
|> this is an abuse of the inheritance mechanism, an example of the
|> reason why inheritance has been branded by some as the "GOTO of the
|> Nineties".  In fact, such inheritance schemes can even *get in the
|> way* of more "legitimate" uses of inheritance that do implement
|> generalization/specialization relationships.

I think this is a natural and appropriate use of inheritance.  To review,
the scheme in question is: 

    package Type_1_Parent_Package is
       type Type_1_Parent is tagged null record;
       type Type_1_Pointer is access all Type_1_Parent'Class;
    end Type_1_Parent_Package;

    package Type_2_Parent_Package is
       type Type_2_Parent is tagged null record;
       type Type_2_Pointer is access all Type_2_Parent'Class;
    end Type_2_Parent_Package;

    with Type_2_Parent_Package;
    package Type_1_Parent_Package.Refinement is
       type Type_1 is new Type_1_Parent with private;
       -- declaration of various primitive Type_1 subprograms, including
       --   some involving Type_2_Pointer
    private
       type Type_1 is new Type_1_Parent with
          record
             Associated_Type_2_Value: Type_2_Pointer;
             -- other components
          end record;
    end Type_1_Parent_Package.Refinement;

    with Type_1_Parent_Package;
    package Type_2_Parent_Package.Refinement is
       type Type_2 is new Type_2_Parent with private;
       -- declaration of various primitive Type_2 subprograms, including
       --   some involving Type_1_Pointer
    private
       type Type_2 is new Type_2_Parent with
          record
             Associated_Type_1_Value: Type_1_Pointer;
             -- other components
          end record;
    end Type_2_Parent_Package.Refinement;

The type Type_1_Parent models some real-world entity, perhaps an office
or an employee.  When a type models a real-world entity, it does not
model every property of that entity, only those that are relevant to the
intended use of the type.  For example, a type modeling an employee might
not include a Favorite_Scotch component if that information is not
relevant to the application.  The only feature of Type_1_Parent is its
ability to be pointed to by a Type_1_Pointer value.

The type Type_1 is a specialization of Type_1_Parent.  The real-world
entity it models happens to be the same as that modeled by Type_1_Parent,
but it provides a more specialized VIEW of that entity, one that offers
not only the ability to be pointed to by a Type_1_Pointer value, but a
number of primitive subprograms as well.  An instance of Type_1 "is an"
instance of Type_1_Parent, because it can be used in the same way as any
other instance of Type_1 (and in additional ways as well).

There is nothing wrong with a class and a subclass modeling the same
real-world entity, but with the subclass providing a more specialized
view of that entity, with a more complete programming interface.

--
Norman H. Cohen    ncohen@watson.ibm.com