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/26
Message-ID: <EACHUS.98May26090217@spectre.mitre.org>#1/1
X-Deja-AN: 356618048
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>
Organization: The Mitre Corp., Bedford, MA.
Newsgroups: comp.lang.ada
Date: 1998-05-26T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <matthew_heaney-ya023680002205981805440001@news.ni.net> matthew_heaney@acm.org (Matthew Heaney) writes:

 > Furthermore, this split is only required when there's mutual dependency. 
 > Most types are definitely not mutually dependent, and so this workaround
 > should only seldom be necessary.

    I would argue, from experience, that every time I have found an
apparent need for this mutual dependency, it indicates I have not
fully studied the problem.   For example in John's example of
employees and offices, it quickly becomes obvious that not all rooms
are offices, and not all people are employees, so you end up needing
at least one of the parent classes for other reasons.

    Note also that once both types have been declared, the needed
operations with the static checks can be declared, you just have this
annoying artifact of a visible function which is implicitly required
to do a static check at run time.  What really is needed is a language
independent way to "cast away 'CLASS" and move the check from within
the subprogram to a (required) static type check at the location of
the call.  This certainly can be done by a pragma.  In fact you would
think that pragma Restrictions (No_Dispatch) would do precisely that,
but it is too restrictive, outlawing all cases of 'CLASS.

    So I suggest that we need a pragma Static_Dispatch which directs
the compiler to eliminate dispatching tables for the named unit and to
reject any unit which calls the unit in a way that requires
dispatching.  Of course, if the unit is called from within any other
primitive operation of the type, that operation will also require the
pragma, so maybe a better solution is to have the pragma apply to (all
the primitive operations of) a type, but not to primitive operations
of types derived from that type.  Since its indended use is for those,
usually abstract, parent types in situations like this, the effect
would be to outlaw dispatching call using Person'Class or Room'Class,
but allow dispatching on Employee'Class or Office'Class.

    Obviously, implementations can add such a pragma, and if it does
become standard, the only remaining question is whether it belongs in
Annex H or as a part of the core.
--

					Robert I. Eachus

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