Re: pseudo-specs for a String class

2008/8/27 Amos Jeffries <squid3_at_treenet.co.nz>:

> 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.

Well in a completely amusing twist of fate, a large part of the MemBuf use gets
thrown away when you start providing a better string interface. Crazy but true.

> 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.

How's that disagreeing with me? I said a String is a region of memory
with "more" than just a region of memory. It'll have some kind of
behaviour and more manipulation functions around whatever we define
String as being.

Just don't define String as being "UnicodeString" off the bat, or
things will get slightly complicated, and don't define String as
"array of bytes of memory" as then certain things like "strcasecmp()"
have little meaning.

> 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.

Hm, Alex/Duane/Robert/Henrik, what did Whale call all of this? I
thought this was one area that was "done" and gels pretty well with
what we've since learnt..

Adrian
Received on Wed Aug 27 2008 - 13:05:20 MDT