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: fraser@synopsys.like.how.smart.are.email.greppers.anyway.com
Subject: Re: Can't export object of private type
Date: 1999/02/25
Message-ID: <7b47m3$l2l$1@remarQ.com>#1/1
X-Deja-AN: 448418601
References: <7b1k4h$13k6@news3.newsguy.com> <F7p7Dq.DE1@syd.csa.com.au>
X-Complaints-To: newsabuse@remarQ.com
X-Trace: 919970307 KZBGBQC4S164892E1C usenet76.supernews.com
Organization: Vegetarian Ada Programmers
Newsgroups: comp.lang.ada
Originator: fraser@titanic
Date: 1999-02-25T00:00:00+00:00
List-Id: <comp.lang.ada>

paene lacrimavi postquam nospam@thanks.com.au scribavit:

>Actually, I don't necessarily want to do that. What I'm really after 
>is polymorphic singletons - objects that
>
>  1) Have only one instance
>  2) Are polymorphic
>  3) Are visible to clients
>  4) Can be called without a package prefix.

What about a parameterless function that returns that type?  The only
down side being that you'd have to override it for each extension.
Or maybe that's not a down side, depending on what you want to do.

package Test is

   type T is tagged private;
   procedure Do_Something (With_T : T);

   function P return T;
    --  function P return T'Class might also be what you want.

private

   type T is tagged null record;

end Test;

>:>   package Singleton is
>:> 
>:>     type Singleton_Type is tagged private;
>:>     type Access_Singleton_Type is access all Singleton_Type'Class;
>:> 
>:>     procedure Do_Something (S: in Singleton_Type);

What about "procedure Do_Something (S : access Singleton_Type)", to
avoid a bunch of S.all's everywhere.

For some reason, and it's probably just me, I see the use of .all as a
sort of failure on my part.  It's probably grows out of that thing
C has where '.' is different to '->', even though there's no earthly
reason why the concepts should be separated.  And even worse, C++ lets
you overload the '->' operator, which is just too evil to contemplate.

I just love the way Ada compilers fill in .all for me.  It's so
helpful, and I feel bad when I write code that prevents it from doing
so.  It's like punishing a puppy because it didn't do the dishes.

Oh, not to mention that the C++ model of overloading changes the
darn calling semantics for certain operators.  I mean, at least in
Ada when you say 'X and then Y' you *know* that Y won't be evaluated
unless X is true.  Overloading means that there's no such guarantee
in C++ for the similar 'X && Y'.

Fraser.
(only ranting because I have to use C at work).