From: John Volan <johnv@ac3i.dseg.ti.com>
Subject: Re: Mutually dependent private types
Date: 1998/05/29
Date: 1998-05-29T00:00:00+00:00 [thread overview]
Message-ID: <356F409A.5D9CEE33@ac3i.dseg.ti.com> (raw)
In-Reply-To: EACHUS.98May27105745@spectre.mitre.org
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. :-)" );
next prev parent reply other threads:[~1998-05-29 0:00 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-05-21 0:00 Mutually dependent private types adam
1998-05-21 0:00 ` John Volan
1998-05-21 0:00 ` Matthew Heaney
1998-05-22 0:00 ` John Volan
1998-05-22 0:00 ` Matthew Heaney
1998-05-26 0:00 ` Robert I. Eachus
1998-05-26 0:00 ` John Volan
1998-05-27 0:00 ` Robert I. Eachus
1998-05-29 0:00 ` John Volan [this message]
1998-05-27 0:00 ` Jerry van Dijk
1998-05-29 0:00 ` John Volan
1998-05-26 0:00 ` John Volan
1998-05-26 0:00 ` Matthew Heaney
1998-05-27 0:00 ` John Volan
1998-05-27 0:00 ` Matthew Heaney
1998-05-28 0:00 ` John Volan
1998-05-28 0:00 ` Matthew Heaney
1998-05-29 0:00 ` John Volan
1998-05-29 0:00 ` Brian Rogoff
1998-05-29 0:00 ` John Volan
1998-05-29 0:00 ` Brian Rogoff
1998-05-29 0:00 ` John Volan
1998-05-30 0:00 ` Geoff Bull
1998-05-30 0:00 ` Fergus Henderson
1998-06-01 0:00 ` John Volan
1998-06-02 0:00 ` Fergus Henderson
1998-06-04 0:00 ` Robert Dewar
-- strict thread matches above, loose matches on Subject: below --
1998-05-22 0:00 adam
1998-05-22 0:00 ` Brian Rogoff
1998-05-22 0:00 ` Matthew Heaney
1998-05-22 0:00 ` John Volan
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox