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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,90108ed846e3f1bf
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news4.google.com!feeder.news-service.com!newsfeed.freenet.de!newsfeed00.sul.t-online.de!t-online.de!tiscali!newsfeed1.ip.tiscali.net!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Sat, 28 Feb 2009 16:36:43 +0100
From: Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de>
Reply-To: rm.tsoh+bauhaus@maps.futureapps.de
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Why constructing functions is a mess [was Language lawyer
 question:
 task activation
References: 
 <ccf8fc4b-80e3-4732-84e3-16c4e2d10c3d@v39g2000pro.googlegroups.com>
  <1dusr7frk73m7.nlsagplge0hk.dlg@40tude.net>
 <09a7aab3-d105-4a40-b25b-e2824cb12f89@j1g2000yqi.googlegroups.com>
 <rv6zobw6fror.csu22kh631qi$.dlg@40tude.net>
 <24bdd0df-9554-49de-9c5e-99572c9cdf34@g38g2000yqd.googlegroups.com>
 <d1d318e7-9cd8-4f28-9cc8-afa3752e711e@g38g2000yqd.googlegroups.com>
 <1v0f2pkso7p50.vein84avao5t.dlg@40tude.net>
 <499ede41$0$32665$9b4e6d93@newsspool2.arcor-online.net>
 <1lhxmo6l2ypux.bei2ffp1m3e$.dlg@40tude.net>
 <499f2c59$0$31868$9b4e6d93@newsspool3.arcor-online.net>
 <1vcaimc8kjj30$.kf3rsd670ebp$.dlg@40tude.net> <go9t07$lht$1@munin.nbi.dk>
 <1gxn72yzshp07$.6ytqydmmz37u.dlg@40tude.net>
 <49a92c29$0$32670$9b4e6d93@newsspool2.arcor-online.net>
 <1wzjy9pzbft1m.1lut7nszfkzmp$.dlg@40tude.net>
In-Reply-To: <1wzjy9pzbft1m.1lut7nszfkzmp$.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <49a95a12$0$31347$9b4e6d93@newsspool4.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 28 Feb 2009 16:36:50 CET
NNTP-Posting-Host: 23c0ee3b.newsspool4.arcor-online.net
X-Trace: 
 DXC=d=^JCL\02]WHigV@eW57PQ4IUK<Cl32<Q4Fo<]lROoRQ^YC2XCjHcbY[88=e1C@hkPA:ho7QcPOVSm>CHHjcW02Vn\Gf_kGHEZZ
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:3850
Date: 2009-02-28T16:36:50+01:00
List-Id: <comp.lang.ada>

Dmitry A. Kazakov wrote:

> 3. You still cannot publicly extend T if you have to add some new
> discriminants. Discriminants still are not properly abstracted.

Yes.

> (This cannot be saved, it is just wrong.)
> 
>>> In order to be used in
>>>
>>>    type S is new T with ...;
>>>    function Create (....) return S;
> 
>> (Deriving publicly
>> from an abstract limited type with unknown discriminants--to me,
>> the <> signals the intent of the author of T, namely that T
>> should be considered none of our business?)
> 
> Exactly. This is why a user of public T must be able to construct T knowing
> nothing about the discriminants of T.

I meant to say that the derivation should not work in the
following sense. T being (<>)ed, abstract, and limited means,
clients are supposed to not even try to create objects of this
type. The choice is deliberate. There is no way to construct
objects of type T. There is no way to construct objects that
somehow involve T objects, e.g. objects of types derived from
T publicly. The (<>)'s message is that T's objects are handled
in the private part.  None of our business.

>>> Remember? Constructor is not function. It never will. See the problem?
>> Assuming C++ has constructors, will your arguments apply
>> in the following examples (just trying to understand):
>>
>> class T
>> {
>> public:
>>   virtual void op() = 0;
>> private:
>>   T(char constraint) : c(constraint) {}
>>   char c;
>> };
> 
> No, the constructor in the example must be public.

The constructor is private because T(<>) has private
constratints only. IOW, clients cannot construct
an object either of class T (C++) or of type T(<>) (Ada).

> Probably you refer to
> the trick when <> is used to prevent uninitialized objects. But T is
> already abstract. You cannot create it in any way.

When S is derived from some public T without a (<>),
I can name T in S'(T with ...) when T is just abstract.
This illustrates that (<>) prevents (meaningful) public derivation.
An abstract T is just a means to allow concrete types derived
from T. (<>)ing T says, "Keep your hands off!".