From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <michael.walter@gmail.com>
Delivered-To: caml-list@yquem.inria.fr
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78])
	by yquem.inria.fr (Postfix) with ESMTP id B9D7FBC48
	for <caml-list@yquem.inria.fr>; Fri, 11 Mar 2005 15:46:17 +0100 (CET)
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194])
	by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j2BEkHA9018137
	for <caml-list@yquem.inria.fr>; Fri, 11 Mar 2005 15:46:17 +0100
Received: by rproxy.gmail.com with SMTP id f1so898270rne
        for <caml-list@yquem.inria.fr>; Fri, 11 Mar 2005 06:46:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=nhP0BWYON5So9g7neIrETWWrAwS5vZdM9CpSqJNehFH5e5aUNOi8ltmNldMB5OYFYqvz6r/lNhAPXBg/WmyQYC4+K5RzKIbSg41mby6e5i1cpvB79rjC9SYypy868yXUk1ajW3L6VEggByf/3XfGyueC24+XoWqqwzFZhdzPdCE=
Received: by 10.38.90.51 with SMTP id n51mr2779703rnb;
        Fri, 11 Mar 2005 06:46:16 -0800 (PST)
Received: by 10.38.86.60 with HTTP; Fri, 11 Mar 2005 06:46:16 -0800 (PST)
Message-ID: <877e9a1705031106467e3d6fd9@mail.gmail.com>
Date: Fri, 11 Mar 2005 09:46:16 -0500
From: Michael Walter <michael.walter@gmail.com>
Reply-To: Michael Walter <michael.walter@gmail.com>
To: Jon Harrop <jon@ffconsultancy.com>
Subject: Re: [Caml-list] Re: exception safety / RAII ?
Cc: caml-list@yquem.inria.fr
In-Reply-To: <200503101652.01848.jon@ffconsultancy.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <293072a520e3724a0497e6456a8675be@mac.com>
	 <200503091619.40419.jon@ffconsultancy.com>
	 <871xan7f9q.fsf-monnier+gmane.comp.lang.caml.inria@gnu.org>
	 <200503101652.01848.jon@ffconsultancy.com>
X-Miltered: at nez-perce with ID 4231AF39.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)!
X-Spam: no; 0.00; caml-list:01 finalizers:01 trivial:01 wrote:01 exception:01 short:01 opengl:01 thread:02 external:02 output:02 output:02 let:03 generally:03 needing:04 applied:04 
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr
X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_BY_IP autolearn=disabled 
	version=3.0.2
X-Spam-Level: 

On Thu, 10 Mar 2005 16:52:01 +0000, Jon Harrop <jon@ffconsultancy.com> wrote:
> > Can you give examples where it's useful?  I don't consider "not needing to
> > call `close' on line NNNN of my code" to be useful.
> 
> OpenGL display lists from earlier in this thread.

Typically you manage your rendering resources at well-defined points
in the life time of a program (for performance reasons -- for
performance reasons you probably also wouldn't use display lists, but
that is besides the point), so I don't see how this is a problem

> > > In the case of files, yes.  More generally, this can be applied to all
> > > sorts of external resources where that is not true.
> >
> > Might be: there's no way we can generalize.  I'm talking about files here.
> > Finalizers are great, but they shouldn't be used for files.
> 
> Let me try another file-specific example then: Programs which save output at
> some point during their execution. From the users point of view, there is no
> "visible" difference between having the program close the file as soon as
> writing is complete and leaving it up to the GC to close the file a short
> time afterwards (and before it completes). I have many such programs.

You might want to be able to process the output file as soon as it's
written, not as soon as the GC decides to close the file. Also,
wouldn't it be trivial to just implement it "the nice way" (maybe I
think of different cases where "programs [..] save output")?

Michael