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.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Unknown constraints and type composition
Date: Thu, 14 Jun 2018 18:19:57 +0200
Organization: Aioe.org NNTP Server
Message-ID: <pfu4jf$brh$1@gioia.aioe.org>
References: <pfu23n$csb$1@dont-email.me>
NNTP-Posting-Host: CvkHMVp693S8Z+lk11jyqg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
X-Notice: Filtered by postfilter v. 0.8.3
Content-Language: en-US
Xref: reader02.eternal-september.org comp.lang.ada:53102
Date: 2018-06-14T18:19:57+02:00
List-Id: <comp.lang.ada>

On 2018-06-14 17:37, Alejandro R. Mosteo wrote:
> I think I have read somewhere that types with unknown constraints are a 
> good way of ensuring you (or your users) don't end with uninitialized 
> values:
> 
> types Whatever (<>) is [limited] private;
> 
> function Create return Whatever;
> 
> This seems nice at first sight but when these types have any likelihood 
> of ending as members of another type you will hit the "unconstrained 
> member" problem.

As well as problems with publicly derived types.

> A workaround then is to use a Indefinite_Holder, but that's an 
> imposition on your clients (ugly). If your type is furthermore limited, 
> then you must use pointers and consider providing controlledness and 
> deallocation in the enclosing type (uglier).
> 
> Right now I'm on the point of a new design where I have many 
> interrelated types that require initialization calls (it's a C binding). 
> And, as always, I'm unsure of the way to go, or if I'm missing another 
> technique without shortcomings. Your thoughts if you have any on this 
> issue are much appreciated.

Without constructors there is no solution to the problem.

In large projects instead of holder I use a reference-counted controlled 
handle. The target's type declaration goes into private packages. The 
handles go to the public interface packages. It is tedious [*], but it 
the only working method if you want to enforce construction and hide 
implementation.

-----------------------
* Because of parallel types hierarchy, lack of delegation support, lack 
of interface inheritance.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de