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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e31963013a17b383 X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: "Inefficiency" of controlled types Date: 1997/07/02 Message-ID: #1/1 X-Deja-AN: 253983735 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1997-07-02T00:00:00+00:00 List-Id: Simon Wright (simon@pogner.demon.co.uk) wrote: : mheaney@ni.net (Matthew Heaney) writes: : > with Ada.Finalization; : > packages Stacks_G is : > : > type Root_Stack is abstract tagged private; : > ... : > private : > : > type Root_Stack is : > new Ada.Finalization.Controlled with null record; : > : > end Stacks_G; : This is a slightly different set of questions from Matthew's: : What happens if I derive a type from Root_Stack and declare a : primitive subprogram Finalize? : Does it make a difference if the package in which I do the derivation : is a child of Stacks_G? Yes. Only if the fact that Root_Stack is controlled is visible can you override its finalize operation (which was in turn inherited from Controlled). This would be visible in the child (in its private part), but not in some unrelated unit. : It seems intuitive to me that I need to expose the derivation from : Controlled in the public part of Stacks_G if Finalize is to behave as : expected; but there was that long thread recently about visibility of : components and (as I recall) operations which might indicate : differently (or even, in the case of child packages, that there was no : point in my doing so!) : Seems to me that if the type is controlled I should make it visibly : so, so that users know that I need finalization and can arrange to : call my Finalize (Initialize, Adjust) from theirs. That is true if you want the user to override your Finalize, but also call it as part of theirs. However, see below... : The rule I've adopted is to say : My_Type is new Ada.Finalization.Controlled with private; : and then in the private part to derive from the type whose eventual : root is Controlled. This works, but I think it is less robust than making individual components clean up after themselves. When you add additional components via type extension, and some of those components need some cleanup action, then those components should themselves be controlled, rather than moving the Finalize operation up to the enclosing type. In this way it makes no difference how the type being extended was implemented, or whether it is derived from Controlled. The only time I would make a type visibly derived from Controlled is when there is a clear semantic action (over and above storage reclamation) that the type and all its extensions should associate with the end of an object's lifetime. For example, a windowing system might define that Finalize should do some special thing, such as erasing the window, or whatever. In this case, making the type visibly derived from Controlled might make sense (though even then, it might be better to have some other operation, and have the root type's Finalize redipatch to this other operation). This is a style issue, of course... : -- : Simon Wright Work Email: simon.j.wright@gecm.com : GEC-Marconi Radar & Defence Systems Voice: +44(0)1705-701778 : Command & Information Systems Divsion FAX: +44(0)1705-701800 -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA