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,772ae8afc5db35f2
X-Google-Attributes: gid103376,public
From: Samuel Mize <smize@imagin.net>
Subject: Re: Can't export object of private type
Date: 1999/03/01
Message-ID: <7beeqo$2o4d@news1.newsguy.com>#1/1
X-Deja-AN: 450025058
References: <7b1k4h$13k6@news3.newsguy.com> <F7p7Dq.DE1@syd.csa.com.au>
 <7b4517$2bbr@news3.newsguy.com> <m3d82u17lb.fsf@mheaney.ni.net>
Organization: ImagiNet Communications, Ltd.
User-Agent: tin/pre-1.4-981002 ("Phobia") (UNIX) (AIX/3-2)
Newsgroups: comp.lang.ada
Date: 1999-03-01T00:00:00+00:00
List-Id: <comp.lang.ada>

Matthew Heaney <matthew_heaney@acm.org> wrote:
> Samuel Mize <smize@imagin.net> writes:
> 
>> By "singleton" and (1) you mean that there can exist only one object
>> of the type.  But a visible type makes that impossible to ensure, so
>> the approach you were taking is fatally flawed.  Oh, the humanity.
> 
> This is incorrect.  Implement the type as tagged, limited, and
> indefinite, which prevents anyone from declaring instances of the type.

Good point.  I haven't done enough with abstract types.

>> I would represent each singleton with a package, which gives 1 and 3,
>> and use programming by extension to get points 2 and 4.  Specifically,
>> we start with:
> 
> I like the idea of a state machine package, but he wants dynamic
> dispatching.  

The code I showed did dispatch, based on an identity value -- which was
implemented as a tagged type.  You show another good solution.

In effect, I implemented the singleton as a state-machine package,
with a tagged "identity" or "flag" type for dispatching to the right
package.  The data is hidden inside the package body.

You're implementing it as a regular dispatching type, but you're
using the abstract type mechanism to ensure that nobody else can
declare an instance.

Your approach extends better to "n-tons."

On the other hand, mine may make for clearer code inside the
singleton packages, since you don't have to refer to everything via
the operation's access parameter.

Mine had the very moderate advantage that you only need to wait for
elaboration of the package spec in order to get at the identity of
the singleton (i.e., if a user package calls P.Q.Ref in its spec, it
has to use an elaboration pragma to ensure that P.Q's body has been
elaborated first.

Of course, your approach is a better conceptual match to a development
environment that's heavily using object-oriented methods.

Looks to me as if they're both worth keeping in the back pocket. :-)

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam