On Mon, Feb 11, 2008 at 03:34:34PM +0100, Jean-Christophe Filliâtre wrote:
> With Rbuffer, the value passed to create is the size of each chunk in
> the rope (roughly), so passing a value such as 10 and then appending
> millions of characters will result in a lot of allocations for rope
> nodes, and will make Rbuffer less efficient than Buffer. But if you pass
> a value large enough, i.e. of the same order of magnitude as the size of
> the final buffer, then it should be as efficient as Buffer.

maybe in this case you should add a minimum limit, so that people
doesn't create rbuffer with 10 or something.

just a simple:
let create sz =
	let sz = max sz my_rbuffer_limit in

> > one nit, keeping compatibility is good, however, the contents function
> > is quite evil (runtime failure), and removing it would be nice as well.
> 
> I agree that a failure of "contents" can be surprising, but I don't like
> the idea of removing it at all (in particular because you may want to be
> able to substitute Rbuffer for Buffer in yours programs to compare
> efficiencies).

I don't really like removing it either, but people need to know that
contents (as in Rbuffer.t -> string) could be evil.

> > people should use other thing to "iterate" over the contents (even if
> > contents is quite practical)
> 
> do you mean something like "iter : t -> (char -> unit) -> unit"?
> 
> (It could be implemented more efficiently than a repeated use of "nth")

iterate in a broad sense; beeing able to do something with what's inside
the buffer.  it could be a list of string, chunks, char, etc ...

-- 
Vincent Hanquez