On Wed, 2008-08-27 at 15:58 +0200, Kinkie wrote:
> > 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.
My vote is not to vote until it is clear what you are implementing.
The original discussion was about meaningful strings and opaque buffers
they will use. Then you said that you are not implementing a string,
just a buffer. Right now, I have no idea what you are implementing so I
cannot suggest a name for it.
Since your code is going to be isolated, it would be easy to rename your
classes during the review process.
HTH,
Alex.
Received on Wed Aug 27 2008 - 17:44:36 MDT
This archive was generated by hypermail 2.2.0 : Thu Aug 28 2008 - 12:00:08 MDT