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: John Volan <johnv@ac3i.dseg.ti.com>
Subject: Re: Mutually dependent private types
Date: 1998/05/29
Message-ID: <356F409A.5D9CEE33@ac3i.dseg.ti.com>#1/1
X-Deja-AN: 357793132
Content-Transfer-Encoding: 7bit
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>
 <EACHUS.98May27105745@spectre.mitre.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Organization: Raytheon Systems Company, Advanced C3I Systems
Newsgroups: comp.lang.ada
Date: 1998-05-29T00:00:00+00:00
List-Id: <comp.lang.ada>


Robert I. Eachus wrote:
> 
> In article <356B6D65.BD34E3EF@ac3i.dseg.ti.com> John Volan <johnv@ac3i.dseg.ti.com> writes:
> 
>   > 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.  

Of course Ada95 has no "problem" with this declaration -- but I have a
problem with this declaration, because what I'd really want is:

  function Get_Assigned_Employee (Office : in Office_Type)
    return Employees.Employee_Type'Class;

> In the body, you will return a value
> of Employees.Employee_Type'Class, again no problem.  

Again, Ada95 has no problem implicitly upcasting an Employee_Type'Class
object to Person_Type'Class -- but I have a problem with that, because
the upcast is spurious.  This subprogram is contracting to return
specifically an Employee, not just any kind of Person, but Ada95
prevents me from expressing that.

> 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;

I assume you mean that Office_Type was implemented as:

  type Office_Type is new Rooms.Room_Type with
    record
      ...
      Occupant : Persons.Person_Type'Class;
      ...
    end record;

Actually it would probably be:

  type Office_Type is new Rooms.Room_Type with
    record
      ...
      Occupant : Persons.Person_Access_Type; -- (access to classwide)
      ...
    end record;

Unfortunately, what I really wanted was:

  type Office_Type is new Rooms.Room_Type with
    record
      ...
      Occupant : Employees.Employee_Access_Type;
      ...
    end record;

>    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));

You probably meant:

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

But what is the "template"?  If you're saying Check_Assignment is
declared as:

  procedure Check_Assignment
    (Office   : in Office_Type;
     Employee : in Employees.Employee_Type'Class);

then of course you have to do an explicit downcast from
Persons.Person_Type'Class to Emploeyes.Employee_Type'Class.  That's
Ada95, no new pragma needed.  But it's impossible to declare
Check_Assignment this way in the spec of package Offices.

However, if you're saying Check_Assignment is declared as:

  procedure Check_Assignment
    (Office   : in Office_Type;
     Employee : in Persons.Person_Type'Class);

Then your pragma must somehow magically assert, without having any
visibility to the Employees package, that the Employee parameter is
actually Employee.Employee_Type'Class, even though Ada95 only allowed
you to say Persons.Person_Type'Class.

>    Or better, put the coercion in the local variable declaration:
> 
>    Employee: Employees.Employees_Type'Class := Office.Occupant;

You probably meant:

  Employee : Employees.Employee_Type'Class :=
    Employees.Employee_Type'Class(Office.Occupant);

However, the point is that I shouldn't have had to upcast and downcast
at all. The Employee/Occupant should have just remained an
Employees.Employee_Type'Class object at all times.

-- 
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. :-)" );