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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,56dbd715fa74735a
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Mutually dependent private types
Date: 1998/05/27
Message-ID: <EACHUS.98May27105745@spectre.mitre.org>#1/1
X-Deja-AN: 356996191
References: <6k25ra$6j7$1@nnrp1.dejanews.com>
 <matthew_heaney-ya023680002105982333070001@news.ni.net>
 <3565B105.9BFB4788@ac3i.dseg.ti.com>
 <matthew_heaney-ya023680002205981805440001@news.ni.net>
 <EACHUS.98May26090217@spectre.mitre.org> <356B6D65.BD34E3EF@ac3i.dseg.ti.com>
Organization: The Mitre Corp., Bedford, MA.
Newsgroups: comp.lang.ada
Date: 1998-05-27T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <356B6D65.BD34E3EF@ac3i.dseg.ti.com> John Volan <johnv@ac3i.dseg.ti.com> writes:

  > Hold on a minute there!  You're falling into the "reality" fallacy:
  > That's where one relies too heavily on philosophical (and supposedly
  > "objective") knowledge about "real-world" objects to guide the design of
  > software objects.  Software objects shouldn't be grab-bags of irrelevant
  > domain information, they should be encapsulations of the actual
  > responsibilities of an actual target system.

   You are reasoning from my specific example that I am relying on
reality as an inspiration.  Most often the need for an enclosing types
comes from the need to add mix-ins.  Yes you can hide the "real"
parent type in the private part in some cases, but in Ada 95, the real
parent type is often Ada.Finalization.Controlled.

  > This makes no sense to me.  The entire raison d'etre for abstract
  > classes such as Person and Room would be precisely for polymorphic
  > dynamic dispatching!  Surely the kind of pragma you suggest should be
  > applied to "spurious" superclasses that are meant to act merely as
  > forward type declarations, e.g., Employee_Forward_Type and
  > Office_Forward_Type.

    I may not have been clear in what I said, but that is exactly the
intent.  For example, take your declaration:

  function Get_Assigned_Employee (Office : in Office_Type)
    return Persons.Person_Type'Class;

   The pragma wouldn't disallow the declaration, and since this
function does not dispatch on Employees.Employee_Type'Class, there is
no problem in the declaration.  In the body, you will return a value
of Employees.Employee_Type'Class, again no problem.  But assume that
for some reason you want to have a class-wide variable in there, and
dispatch on it:

   Employee: Persons.Person_Type'Class := Office.Occupant;

   So far also okay.  But if you call some operation on Employee:

   Check_Assignment(Office,Employee);

   That call, even if it matched the template, would be illegal, you
would have to say:

   Check_Assignment(Office, Employees.Employee_Type(Employee));

   Or better, put the coercion in the local variable declaration:

   Employee: Employees.Employees_Type'Class := Office.Occupant;

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...