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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.84.215.220 with SMTP id g28mr8095188plj.59.1505374109694; Thu, 14 Sep 2017 00:28:29 -0700 (PDT) X-Received: by 10.36.125.198 with SMTP id b189mr59290itc.6.1505374109649; Thu, 14 Sep 2017 00:28:29 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!paganini.bofh.team!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!o200no227287itg.0!news-out.google.com!p6ni522itp.0!nntp.google.com!127no228197itw.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 14 Sep 2017 00:28:29 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=76.113.16.86; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 76.113.16.86 References: <364ff8e0-c7dd-4980-b19f-5d438edd8353@googlegroups.com> <7df81b3c-1fde-4395-8b9b-1a945820a7f7@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <45fe84b9-3fea-44e9-ab87-c91370a0cd2e@googlegroups.com> Subject: Re: Type invariants and private extensions? From: Shark8 Injection-Date: Thu, 14 Sep 2017 07:28:29 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:48124 Date: 2017-09-14T00:28:29-07:00 List-Id: On Tuesday, September 12, 2017 at 4:59:17 PM UTC-6, Victor Porton wrote: >=20 > Thanks. >=20 > But this seems not to solve my problem: >=20 > The base type for Example cannot be defined as a discriminated type for= =20 > certain Type_Enumeration, because it is possible that when creating the= =20 > object it may be yet unknown what the value of the discriminant should ha= ve=20 > (my main problem is to invent somethings if this value is known at object= =20 > creation, but we must support the unknown case too). AFAIK, it is not=20 > possible to change the discriminant later. What are you doing that you need to create an object w/o knowing the types?= I've used the variant-record approach in several interpreters to excellent= effect; I've also used tagged-type hierarchies, too. Perhaps what would be more called for in your design is an abstract base ty= pe with a discriminant, then having the child-types use the proper value an= d using Base'Class variables/returns as needed: Type Base( Item_Type : Type_Enumeration ) is abstract tagged null record; Type Integer is new Base( TInteger ) with null record; Type Boolean is new Base( TBoolean ) with null record; --... >=20 > The solution would be to define a discriminated type as its descendant, b= ut=20 > then all problems which I described in previous messages appear again. So= =20 > this is not a solution. >=20 I think you're tripping yourself up by overcomplicating / underelaborating = on the design. Clear your mind, pull put a piece of paper, and in pen [so y= ou can't erase] write a description of the system being careful to keep it = consistent -- I find it very helpful nailing down a design. (In my experien= ce how you're presenting things is how I feel when I haven't solidified a g= ood design yet, and so things keep swirling out of control... kind of the i= nfinite-loop version of "analysis paralysis".) > Hm, we can make Type_Enumeration to contain the value "Any" to allow any= =20 > result type. This is formally a solution, but it is against OO principles= =20 > such as the principle that derived types should be made by object=20 > inheritance. Wait, it has another more important in practice deficiency:= =20 > Example(Any) would be incompatible with Example(TInteger); this seems not= =20 > acceptable. Again, see the above. > And variant records are certainly not applicable here, as I deal with=20 > (tagged) private types which contain a C pointer only. That actually might be all the more reason to use them: C-pointers are noto= rious for being unsafe WRT type-safety... and a variant-record could certai= nly be used to isolate them and ensure that they are only used in the place= s they ought.