Re: Destructor question

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <74d0i5$itj$1@nnrp1.dejanews.com> david.c.hoos.sr@ada95.com writes:

  > 1.  Robert said "Next, you need, and this need not be visible, to have a
  >     two parameter version that is dispatching on Object"  I do not see how
  >     this can be made invisible, since it needs to be a primitive operation
  >      of the type.  Perhaps someone can enlightne me on this.

   Matt Heane answered this--dispatching operations can be declared
in the private part if they are not part of the exported interface.
But they still have to be declared before the type is frozen (see
3.9.2(13)), and there are certain other limitations. (See 3.9.3(10).)

  > 2.  Robert said "Note that the parameter "The_Object" is never used, it is
  >     just there to get the dispatching."  This would be true if it were not
  >     for your requirement that you be able to deallocate internal
  >     dynamically-allocated components.

   It can be used, but I recommend against it.  In my example, I only
used the access parameter, but if you need to do anything to the
object, I strongly recommend using ".all" applied to the access
parameter.  If someone writes a call where the object type is wrong,
you will get an error at run-time.  But if the object is of the
correct type but not the target of the access parameter, you will have
a very hard to find bug.  It is possible to put an explict check in,
but it is much easier just to avoid using the value of the parameter,
or as Matt suggested, use a single access parameter.  (But then you
have to make a copy to pass to Unchecked_Deallocation, then explicitly
set the outer parameter to null.)
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...