Re: Re: Re: my garbage collector sucks

Paul Prescod wrote:
> The argument that I shouldn't expect my
> language to close files for me is exactly equivalent to the argument of
> five years ago that I shouldn't expect my language to free memory for
> me.

Hear hear.  I agree that dealing with freeing resources other than
memory is hard to implement.  But that is the whole point of a
language environment - do the hard things so that the programmers
don't have to do them.  I find it even more ludicrous that the
very act of adding destructors/finalizers somehow makes it
less likely they will be used.

And as for the argument that you should just clean up after yourself
(ie manually close everything) then why aren't the same people also
claiming you should do the same for memory?

It is also a LOT more complicated manually closing stuff.  A few
months ago I tried to make the standard Python XML-RPC client
and server implementations work over SSL and also do multiple
requests per connection.  After several weeks it almost worked.
The single biggest problem was all the manual closing scattered
all over the code.  When writing library code, it is really
hard to ensure that consumers of your library know when they
must, when they should, and when they could close stuff.
Additionally some items had to be dup'ed because there were
multiple possible control flows which could all do closing
so you needed to ensure the underlying resources were only
actually closed once the last consumer was done with it.
That introduced other problems since items like SSL connections
cannot be dup'ed easily without a proxy class that funnels
everything into one.

Feel free that that it is too hard to implement proper resource
release (except memory) as part of the language environment, but
I wish people would then stop pretending that is as it should be.

Roger