Re: Feature request: plain option for gsub

[Sean Conner <sean@...>]

It was thus said that the Great Coroutines once stated:
> 
> I still stand that an additional optional parameter to gsub would not
> be total nonsense.  Anyway, this whole thing has me thinking that I
> wish "strings" did not exist in Lua.  It's really just userdata and
> sometimes I wish Lua didn't pool strings.  I'd be much happier
> creating a string pool manually if I intend to save on string
> deduplication or copy-on-write situations.  For a long time I've
> wished Lua had more facilities for treating userdata like buffers --
> with the ability to fill/write to them as needed and then promote them
> to strings for pooling.

  One reason I use Lua so I can avoid having to think about string
manipulations.  The above ... sounds complicated.

> sorry, I'm getting off-topic again... I just wish we could have both.
> I wish type('cat') returned userdata and I wish it were possible to
> create mutable strings and promote them to pooled, specially handled
> strings as needed.  If we didn't have immutable, pooled strings by
> default we could do less locking on the Lua state as well.

  Um ... I thought by using immutable data you do less locking, not more, if
I understand the functional programmers arguments.  Could you explain how
mutable strings leads to *less* locking?

> Okay, I'm gonna pack up my crazy now and head home :3
> string.gsub(string, needle, repl, [plain [, n]]) would be easy to get
> used to. 

  I would accept a string.replace() function that doesn't use patterns.  I
will not accept an even more complicated string.gsub() function.  Such a
proposal is leading to a "candy machine interface" that is hard or
troublesome to use [1][2].

  -spc (Although I have to wonder why with string.format(), "%s" does not 
	automatically call tostring() on the parameter ... )

[1]	It's from _Writing Solid Code_, only one of two books that ever
	fundamentally changed how I program (the other being _Thinking
	Forth_, which is available on the web if you look for it).  Even
	though it (_Writing Solid Code_) is mostly a C based book, the
	underlying advice applies to other langauges.

[2]	An example of a "candy machine interface" is the C function
	realloc(), which, depending upon the parameters, either allocates
	memory, resizes memory, or frees memory.  In other words, there are
	(valid) inputs that can do one thing, other (valid) inputs that can
	do the opposite; it's an all singing, all dancing interface to
	memory.

	Another one is strtok().  It's a function I used to use all the
	time, but not anymore.