Version française
Home     About     Download     Resources     Contact us    
Browse thread
OO design
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Till Varoquaux <till.varoquaux@g...>
Subject: Re: [Caml-list] Re: OO design
One rather standard way to preserve atomicity of open/close operation
is to use with... commands:

let with_open_out filename f =
 let chan = open_out filename in
 let res=(try
           f chan
          with e ->
           close_out chan;
           raise e)
 in
 close_out chan;
 res

Where f is the function you want to use to generate f's content (takes
an out_channel).
This forces chan to be closed no matter what happens.


You may also want to have a look at ocamlnet's channel's
implementation (it's OO and might do a lot of you are looking for):
http://ocamlnet.sourceforge.net/refman/Netchannels.html

Cheers,
Till
On 5/10/06, Shawn <shawnw@speakeasy.org> wrote:
> Dan Grossman wrote:
> >
> > I totally agree -- effects limit the class of protocols you can
> > enforce, but I believe (please correct me if I've missed a dirty
> > trick) the "simple stuff" still works fine.  For example:
> >
> > type read;
> > type write;
> > type 'a file;
> > val open_r : string -> read file;
> > val open_w : string -> write file;
> > val write : write file -> char -> unit;
> > val read : read file -> char;
> > val close : 'a file -> unit;
> >
> > It enforces that you don't confuse your reads and writes, but *not*
> > that you don't use a file after you close it.  A monadic approach
> > (where each operation would return a "new" file) or linearity appears
> > necessary for the latter.
> How can an approach like this handle files opened for reading and
> writing at the same time? Hmm. Maybe an OO approach? readable_file and
> writable_file classes, and a read_write_file that inherits from both.
> It'd be easy to add new file-like types too. I'm not normally a big fan
> of OO, but this is a place where it seems to make sense to use. Of
> course, it doesn't do anything about the compile time checking of
> attempts to use a closed file either.
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>