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.2 required=5.0 tests=BAYES_00,FROM_WORDY,
	INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,772ae8afc5db35f2
X-Google-Attributes: gid103376,public
From: "Nick Roberts" <Nick.Roberts@dial.pipex.com>
Subject: Re: Can't export object of private type
Date: 1999/03/01
Message-ID: <7be1p0$mjg$4@plug.news.pipex.net>#1/1
X-Deja-AN: 449932233
References: <7b1k4h$13k6@news3.newsguy.com> <F7p7Dq.DE1@syd.csa.com.au>
 <7b4517$2bbr@news3.newsguy.com> <m3d82u17lb.fsf@mheaney.ni.net>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Organization: UUNET WorldCom server (post doesn't reflect views of UUNET
 WorldCom)
Newsgroups: comp.lang.ada
Date: 1999-03-01T00:00:00+00:00
List-Id: <comp.lang.ada>

Some (purists!) might say that using a type at all gives a "false sense of
abstraction" (because it is 'idiomatic' that a type implies many objects,
rather than just one).  Frankly, I find Matthew's solution so neat I
wouldn't subscribe to that point of view myself.

One little detail is that the primitive operations of T should all (with
possible exceptions) be made abstract, since T is only a 'signature' type,
e.g.:

package P is

  type T (<>) is abstract tagged limited private;

  <primitive ops (abstract)>

  type T_Access is access all T'Class;

  function Ref return T_Access is abstract;

private

  <junk>

end P;

[Aside: the 'possible exceptions' are (almost always) procedures (a) for
which it would be particularly convenient to provide a 'do nothing'
procedure to be automatically inherited (by the majority of derived types),
or (b) which provide the 'backstop' on a call-the-parent chain.]

Matthew's solution is quite like mine (essentially one package per singleton
object), except that he actually employs Ada 95's tagged type dynamic
polymorphism mechanism -- which I strived to avoid (purely for didactic
reasons, of course ;-) -- producing (probably) a far neater solution.

-------------------------------------
Nick Roberts
-------------------------------------