Re: access to controlled types

["news.oxy.com" <Vladimir_Olensky@oxy.com>]

Terry J. Westley wrote in message
<918079635.219550@outpost1.roc.accglobal.net>...
>
>But, there are certain calls in the interface which
>return an access to a class-wide type.  It's easy to
>reference count these newly created objects, but since
>the access type is not controlled, the reference counts
>don't get decremented.  What's the solution?  Should I
>declare another controlled type which *contains* an
>access to the original controlled type?  Or, is there
>a better solution?


I think this is one of the best solutions. I did exactly the same some time
ago when  I was playing  with controlled types aiming at creating some type
of universal class-wide communication objects (controlled types)  that could
work in conjunction with access types to them and all that together should
perform automatic garbage collection.

The problem with the simple access types to the controlled types was that
they do not resolve the problem of deleting  controlled types when there is
no more references to the last ones. Controlled types are only deleted on
leaving their life scope. Object lifetime scope can be reduced by using
internal/local blocks but in many cases this is not an optimal solution.

To resolve that I created and tested small top-level package that performs
user defined garbage collection using controlled access type to the
controlled class-wide types. This package (just small experiment or
exercise) proved to be working fine and I an going to use it  later to
create hierarchy of controlled types with automatic garbage collection.

Just few days ago I remembered one of the questions that was asked somewhere
some time ago (I do not remember where). The problem was how to distinguish
statically created objects at compile time from the dynamically created
objects during run time.
This is very important in conjunction with controlled types as any attempt
to free up static object will raise run-time error. Only dynamically created
objects may be deleted.
 As I understand this issue is not addressed in the LRM (but may be I am
wrong and someone will correct me), so I invented some kind of solution to
resolve this issue an I am going to test it as well when I add that changes
in my package. If that solution (it is extremely simple)  would be used by
the compiler itself then life would be much more easier.

Another issue is that sometimes it is necessary to postpone deleting of the
object in order not to affect performance of your code. This  also can be
easily resolved by creating separate garbage collection process that
performs the delayed  deleting of your object. During finalization (if the
object should be deleted) you just pass reference to your controlled object
to that garbage collection process and that's it. That garbage collection
process can be any structure (list, tree e.t.c.) containing controlled
access type to class-wide controlled types and set of needed operations on
that structure to perform controlled finalization of the objects within that
structure.

I should mention that I am not a programmer. I am telecommunications
engineer so I am playing with Ada occasionally. Also I never read anything
about how garbage collection is implemented in any other system.
What I was describing was just  my own approach to that problem using Ada
facilities.
May be there is something  wrong in what I am doing. May be there exist
better solutions.

As a matter of fact  garbage collection issues have somewhat increased
significance now and maybe it is worth to discuss it in separate discussion
thread. I have some topics for that discussion

Regards,
Vladimir Olensky
(vladimir_olensky@yahoo.com)
(Vladimir_Olensky@oxy.com)
Telecommunication specialist,
Occidental C.I.S. Service, Inc. ( www.oxy.com )
Moscow,
Russia.