Using MEMORY to make a "Destructor" 
Author Message
 Using MEMORY to make a "Destructor"

  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



Tue, 16 Nov 1999 03:00:00 GMT  
 Using MEMORY to make a "Destructor"

Quote:

>   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.

The reason for dispose is for finalisation.

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



Tue, 16 Nov 1999 03:00:00 GMT  
 Using MEMORY to make a "Destructor"

Quote:

>  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.

It is only logical if you limit your view to memory. There are some other
resources, like file handles, locks, ports, etc. The idea of using a
garbage collector may have started with memory in mind (I'm sure it has)
but it applies to other resources as well: leave it to the runtime system
to determine whether an object (and the resource that it encapsulates) is
still needed or not. Reclaiming the resource for the OS is a different and
class-specific task.

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
+-----------------------------------------------------------------------------+



Fri, 19 Nov 1999 03:00:00 GMT  
 Using MEMORY to make a "Destructor"


Quote:


>>  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.

>It is only logical if you limit your view to memory. There are some other
>resources, like file handles, locks, ports, etc. The idea of using a
>garbage collector may have started with memory in mind (I'm sure it has)
>but it applies to other resources as well: leave it to the runtime system
>to determine whether an object (and the resource that it encapsulates) is
>still needed or not. Reclaiming the resource for the OS is a different and
>class-specific task.

>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.

  That's true.  So I'd say that the idea of a destructor is useful when
there is resource freeing that is not time-critical.  If it's time-
critical, it should be done with an explicit function call.

Quote:
>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.

  I'm not sure I follow that last bit about dependencies, but in
referentially-transparent languages where objects are values rather
than entities, objects do (conceptually) live forever.  For example,
when the expression 2+3 is executed, a 5 object is created and never
(conceptually) destroyed.  Of course, one could argue that it was
never created either, and that it "always" existed, but the fact is
that the 5 object never goes away.

  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



Sat, 20 Nov 1999 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. "Destructors" and dynamic pre/post-conditions

2. string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for")

3. making it more "efficient"

4. Colors in "self-made" queue-browse

5. Making F83s6 Desqview "Aware"

6. Kids and "The Making of Android"

7. Kids and "The Making of Android"

8. MAKING "ECHO OFF" SIL

9. making ethernet "driver"

10. Making source code "pretty"

11. gtcatalog (was: "Re: Simple, customizable PHP shopping cart?", but google made me change it)

12. What makes code "readable"?

 

 
Powered by phpBB® Forum Software