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!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Unknown constraints and type composition
Date: Thu, 14 Jun 2018 16:28:40 -0500
Organization: JSA Research & Innovation
Message-ID: <pfumm9$qo3$1@franka.jacob-sparre.dk>
References: <pfu23n$csb$1@dont-email.me>
Injection-Date: Thu, 14 Jun 2018 21:28:41 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk;
 posting-host="rrsoftware.com:24.196.82.226";
	logging-data="27395"; mail-complaints-to="news@jacob-sparre.dk"
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
Xref: reader02.eternal-september.org comp.lang.ada:53108
Date: 2018-06-14T16:28:40-05:00
List-Id: <comp.lang.ada>

"Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message 
news:pfu23n$csb$1@dont-email.me...
...
> 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.

If there was a technique without shortcomings, we wouldn't need any other 
options!!

The other option, of course, is to ensure that the default initialized 
object is "meaningful" in some sense. Most of my objects default initialize 
to a state that causes most operations on them to raise an exception 
("Not_Valid_Error" in Claw). I don't think it is reasonable to try to make 
objects valid 100% of the time, that forces all of your operations into the 
straitjacket of Ada scoping.

That of course has the downside of making the checks dynamic. In the case of 
Claw, there's no choice anyway (a Window object can disappear due to an 
action that comes from the program's user [clicking on the close button], 
not the program's code, so nothing really can be determined statically). I 
suspect that is somewhat true of most real systems.

                                    Randy.