From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Mutually dependent private types
Date: 1998/05/27
Date: 1998-05-27T00:00:00+00:00 [thread overview]
Message-ID: <EACHUS.98May27105745@spectre.mitre.org> (raw)
In-Reply-To: 356B6D65.BD34E3EF@ac3i.dseg.ti.com
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...
next prev parent reply other threads:[~1998-05-27 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 [this message]
1998-05-29 0:00 ` John Volan
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 ` John Volan
1998-05-22 0:00 ` Matthew Heaney
1998-05-22 0:00 ` Brian Rogoff
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox