Re: Proposal: improvement of string.gsub()

[Klaus Ripke <paul-lua@...>]

Hi

put another way, IMHO it is quite appropriate to access a stringbuffer
(using whatever implementation) via an I/O style API rather than
in a string-like fashion.
E.g. a substr is no more convenient than a pread (seek+read).

OTOH for a file/streams API it is next to mandatory to provide
something like a "StringBufferStream",
and using e.g. printf/scanf on such devices is very nice.
We are currently developing such an approach to be used
with our Selene database: functions like reading a record
take an outputstream parameter, which may be a stringbuffer
(say, rope) to finally get the data into lua land,
or e.g. an I/O buffer on a client socket.


And BTW, PA: persistent connections require message boundaries,
and content-length is a rather simple thus robust approach on this,
while chunked encoding is *very* rarely actually needed in practice
and implementations are more often broken than not.


cheers


On Wednesday 20 April 2005 14:44, Mike Pall wrote:
> Hi,
>
> Gavin Wraith wrote:
> > If the final string is actually needed, that is clearly the way to go.
> > In practice, it very rarely is needed. Usually the rope/stringle (sorry
> > "stringle" was an extemporization) gets written out to a file. The point
> > is that ropes are very easy to program in Lua. I doubt whether managing
> > them at the C level gains one very much.
>
> Generally design I/O functions in C to handle both multiple
> arguments and nested tables from Lua. Very easy to work with
> on the Lua side. And fast, too.
>
> Example:
>
> output("foo".."bar".."baz")      -- Slow. Avoid single arg I/O APIs.
>
> output("foo", "bar", "baz")      -- Allow multiple arguments.
> output{"foo", "bar", "baz"}      -- Allow tables.
> output({"foo", {"bar"}}, "baz")  -- Allow nested tables. Mixing args is ok.
>
> Bye,
>      Mike