A while back I said that I thought it was inappropriate to have to
inherit from the MEMORY class to make a destructor for an object.  I
said that it seemed strange to inherit from a rather obscure library
class to implement such a universal feature as a destructor.

  Well, I've changed my mind, and I want to know what Eiffel programmers
think.

  In the ideal "mathematical" world of Eiffel, once an object is created
it is never destroyed.  It so happens that real computers have a limited
amount of memory, so when an object is found to be unreachable, it is
quietly destroyed without the program's knowledge.  This gives the
appearance of a very large memory without actually having one.

  The idea of a "destructor" is all about gracefully destroying an
object; however, in the ideal Eiffel world, objects are never destroyed.
Object destruction is an artifact of our limited non-ideal computers,
and is a reflection of memory management issues.  Therefore, it is
perfectly logical to put destructor features into the MEMORY class.

  Thoughts?

 -PD
--
--
Patrick Doyle

One book on Garbage collection that I have defines finalisation as: a
clean-up action performed on an object when it dies.

A good example of what you would want to clean up would be a resource
aquired from another system, such as the OS. So a file handle would
fall into this category.

One issue with this type of management is that you do not have control
over the order of finalisation, or when it may happen. You can force
matters by garbage collecting. So if the resource is limited, you may
not get a new resource when you want without performing a collection.

As a rule, make sure there is a feature to release the resource
available for the clients to call. For example, to close the file.

--

Nick

So, given this broader view, class MEMORY is the wrong place for a
destructor method. At least it should be renamed to something like
RESOURCE, with a narrower class MEMORY derived from it. One can
then derive other classes that encapsulate a resource and offer
methods to lock and release it.

On a side track, I object to the notion of objects living forever
naturally (whatever nature they have :-) At least those objects
that represent mutable real-world entities in programs to have a
well-defined life-cycle and will have to be (more or less explicitly)
removed from the system at the end of this cycle. The usual problem
is then find out who depends on this particular object, instead of
vice versa as supported by garbage collectors, in order to propagate
its removal properly.

  Juergen Schlegelmilch
--
+-----------------------------------------------------------------------------+
 Dipl.-Inf. Juergen Schlegelmilch                 University of Rostock

 http://www.informatik.uni-rostock.de/~schlegel   Database Research Group
 Tel: ++49 381 498 3402                           18051 Rostock
 Fax: ++49 381 498 3426                           Germany
+-----------------------------------------------------------------------------+

  This integer example is rather trivial, but the idea can be extended
to other more complicated objects.  For example, in the database
world, if I select some subset of rows from a table, then that subset
is a value rather than an entity in the sense that once I've defined
the subset I should be able to refer to it as often as I like for the
duration of the program.  However, if the program determines that
no references exist at a given point, then it's safe to say that
they never will again, and the subset can be deleted from memory without
ruining the illusion that it lasts forever.

  This is not an argument in favour of garbage-collection per se, but
in favour of the view that objects are never destroyed.  Of course, in
a real system, this implies GC.

 -PD

--
--
Patrick Doyle