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!news.eternal-september.org!news.eternal-september.org!mx05.eternal-september.org!feeder.eternal-september.org!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Accessing finalized values Date: Mon, 6 May 2013 19:51:58 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <143a8db3-c14b-4983-a481-4b998aea42af@googlegroups.com> <7a248ba5-9fbc-4326-bbb8-eec3c125d455@googlegroups.com> <5ryqq4azptqx.1evdyl7lvwwg2$.dlg@40tude.net> <56ae2d39-e3a1-4d3e-b9a1-8d4aa435ad8a@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1367887921 15236 69.95.181.76 (7 May 2013 00:52:01 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 7 May 2013 00:52:01 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:15388 Date: 2013-05-06T19:51:58-05:00 List-Id: wrote in message news:56ae2d39-e3a1-4d3e-b9a1-8d4aa435ad8a@googlegroups.com... On Monday, May 6, 2013 5:52:18 AM UTC-4, Dmitry A. Kazakov wrote: >> Finalize is a hack. I disagree with this... >The more I delve into controlled types, the more I'm starting to come to >that > conclusion. This means, in general, that every controlled type must track > the > state of its finalization and conditionally release resources (to > side-step the > non-limited multiple finalization issue), as well as add a 'not > Is_Finalized' > precondition to every single operation (to avoid access after > finalization)? > Yuck. ...but disagree with this. And the main reason is that you have to be able to handle "non-open" objects in any case (consider files -- you have to already have some sort of check for an unopen file). So there is no problem to using that same check for objects that have been finalized. For instance, in Claw, we have "invalid" objects, which is any object that exists, but has not yet been created or has previously been closed (which included finalization). Finalization releases resources making the object invalid. Every operation (other than Create, Close, and Finalize) have to check for whether the object is valid, and raise an exception if it is not. Care must be taken to avoid referencing any components if the object is invalid. There's certainly some level of complication to that, but it's unavoidable for any abstraction that has something like Create and/or Close. It might be more of a problem for abstractions that don't have "Close", but even there there is usually an "empty" abstraction which also works fine. For instance, the Ada containers work this way: they're initialized to empty, and end up empty after finalization, and that's sufficient if the implementation can avoid using an extra resources for an empty container. (If you can't do this, the language requires raising an exception on use, so you'd have to have an extra flag and check.) To summarize, it's a level of complication, but its one you're almost certainly going to have to deal with anyway. The main problem is that it makes most simplistic examples wrong - real examples need checks everywhere anyway (if they're a well-designed Ada abstraction). Randy. -sb