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,2ea02452876a15e1
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Choice of OO primitives in Ada95
Date: 1996/02/21
Message-ID: <EACHUS.96Feb21114109@spectre.mitre.org>#1/1
X-Deja-AN: 140492824
references: <4g2f8v$15lc@watnews1.watson.ibm.com> <Dn0FqH.8Cw@assip.csasyd.oz>
organization: The Mitre Corp., Bedford, MA.
newsgroups: comp.lang.ada
Date: 1996-02-21T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <Dn0FqH.8Cw@assip.csasyd.oz> donh@syd.csa.com.au (Don Harrison) writes:

  > This is an example of what I mean by tight-coupling of
  > abstractions - you are forced to encapsulate both abstractions
  > into a single module.

   Not FORCED to, choose to.

  > An example might best illustrate what I mean. Extending your
  > example and assuming each type is tagged, we might have:

  > package X is
  >   type MARRIAGE is tagged ...
  >   type PERSON is tagged ...
  >   type UNIVERSITY is tagged ...
  >   type GOVERNMENT is tagged ...
  >   type ELECTORATE is tagged ...
  >   type ADDRESS is tagged ...

  >    procedure Enrol (Student : in out PERSON; Uni : in out UNIVERSITY);
  >    procedure Award_Grant (Polies : in out GOVERNMENT; Uni : in out UNIVERSITY);
  >    procedure Make_Gerrymander (Polies : in out GOVERNMENT; Elect : in out ELECTORATE);
  >    function Office_Address (Elect : in ELECTORATE) return ADDRESS;

  > end X;

  > Each abstraction is related to the previous one but isn't
  > necessarily related to any other. As I understand it, the language
  > rules dictate that each of these abstractions must be in the same
  > package. But many of them have nothing to do with each other. They
  > are tightly-coupled even though they should be distinct and this
  > has been forced by the language rules.

    What language rules say this?  The only thing remotely close is
that when you have two types where you want primitive operations of
one with operands of the other, you have to chose one of several
approaches.  ONE of those approaches is to package the types together,
and if they are closely related, it is usually the right choice.
Other choices include using child packages, making the operations on
one type class-wide operations using a parent of the other type,
treating the relation between the two types as its own class,
generics, etc...

    But how would you attack this "problem" in C++?  The "solutions" I
have seen all have the same semantic effect as the Ada solution shown
even though the file layout is usually different.  (The mingling of
the types is via #includes.)

--

					Robert I. Eachus

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