[Prev][Next][Index][Thread]

Re: Object lifetime management

Well, in C++ it is essentailly the destructors.  Because C++ requires 
memory management, destructors are often filled with code that manages 
memory, but that is not their only use.  For example a socket class or file 
class would release other resources they obtained (ports and file 
descriptors).

One needs only to look at the JDBC api for Java to see that all java 
resource management must be done manually (by calling close), and it is 
extremely limited.  One need only consider the case of needing to destruct 
a concrete derived class that has obtained resources, as well as its parent 
class that has obtained resources.  The problem is the child class has to 
make sure that it deletes its parent class resources (hopefully thru a 
method call, but one may not be that lucky).  Furthermore, clients of that 
class have to call that method explicitly, there are no rules allowing that 
that method will be called when that object is no longer needed (i.e. 
dead).  The language has no inherent support for this, because java makes 
no guarantees about object lifetime (thus the finalize method is virtually 
worthless, it may never get called).

In all the papers I've read about Dylan (which is admittedly few), they 
tout the better encapsulation system (generic functions, class data, and 
modules), optional type checking, automatic memory management, but no 
discussion of object lifetime issues.    I don't have a problem letting a 
library manage the resources for me, but I've got to have a mechanism to 
tell the computer to manage those resources.  It appears to me that many 
languages with garbage collection have missed the boat, memory is not the 
only resource I need to have managed, yet that is the only resource they 
will manage.  And then they don't give me a well supported polymorphic way 
to manage those resources (ala C++ destructors).

Essentially, in C++ the way you declare the variable determines its 
lifetime.  This is both good and bad, as it allows automatic lifetime 
management (instances on the stack), but without third party libs, it won't 
manage instances on the free store.  (The reasons I am interested in 
leaving C++ are not related to its lifetime mgmt scheme, which I consider 
flexible and sufficient)

Scott McKay wrote:

> I guess "object lifetime management" means "how do I
> deallocate an object".  As in Lisp, Smalltalk, and Java,
> the answer is: just stop using it, i.e., remove all references
> to it.
> 
> In some sense, this is no different from C or C++, except
> that in C/C++, you have to call 'free' once you have removed
> all references.
> 
> I would be curious to understand better what a "solid lifetime
> management scheme" looks like.  (That's not sarcasm, I
> would really like an explanation.  Respond to me privately
> if you think it's not of general interest.)
> 
> 
>>Brad Settlemyer wrote in message ...
> 
>>  I've recently begun to learn dylan, and am very pleased with some of its
>>advantages over the two languages I am most familiar with (C++ and Java).
>> welcome the use automatic memory management, but I am definitely confused
>>about how to manage object lifetime (Java, of course, has no reliable,
>>standard mechanism for managing object lifetime; C++ has a very solid
>>lifetime management scheme, but it unfortunately requires manual memory
>>management in its stock form -- 3rd party libs can alleviate that
>>problem). Does the dylan language offer inherent support for object
>>lifetime management, or must one use a java esque approach?
> 
> 
> 
>
Follow-Ups: References: