Re: pseudo-specs for a String class

> No. MemBuf would be good, but thats already used. If the assumptions Squid
> makes of MemBuf allow it to be replaced entirely by your buffer object.
> Great re-use the name too.

From what I can tell, it should be possible to replace MemBuf and
String both with RefString (or whatever we'll end up calling it). I'd
avoid overlapping the names during the transition fase tho. After that
it's just a simple sed ;)
Where encoding semantics matter, I'd suggest we subclass string
(probably best with a Delegate pattern to increase performance in the
common case which I expect to be MemBuf)

> I disagree with Adrian on this one, a String is whatever we define a String
> to be. Printable characters or not. After all, an ascii string can have
> whitespace and NULL, and unicode text is 100% binary encrypted blobs at the
> byte level.
> As long as its contents are known to be contiguous in meaning and
> information content it fits the description of String to me. Also, we are
> mostly using them to represent pieces of HTTP Headers, which is a protocol
> built of classical Strings.

> If you are implementing the BetterStringBuffer (next generation) objects,
> I'd go with RefString or similar. Since its ref-counted.
>
> If you want to be pedantic about the printable char issue, DataBuffer makes
> more descriptive sense.

I'm taking votes. Please participate. Candidates:

1- String
2- RefString (interim) -> String
3- RefString
4- MemBlob (interim) -> MemBuf
5- DataBuffer

My vote goes to option 2.

-- 
 /kinkie