Re: "Inefficiency" of controlled types

[stt@houdini.camb.inmet.com (Tucker Taft)]

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