On Sat, Jan 22, 2011 at 1:37 AM, Chad Nelson <chad.thecomfychair@gmail.com> wrote:
On Fri, 21 Jan 2011 20:07:51 +0800 Dean Michael Berris <mikhailberis@gmail.com> wrote:
[...] Mostly I'm interested in seeing a string class that is:
1. Immutable. No if's or but's about it. I don't want a string to be modifiable. Period. You can create it, and once it's created, that's it. [...]
I'm confused by this. You want the basic type to always act as if it's const, with no way to modify the string at ALL after it's been created?
Yep. No changing arbitrary content in the string. Concatenation is a process of creating new strings.
I think strings are different from the encoding they're interpreted as. Let's fix the problem of a string data structure first then tack on encoding/decoding as something that depends on the string abstraction first.
That gets back to the problem that I was originally trying to solve with the UTF types: that a string needs a way to carry around its encoding. A UTF-8 type could be built on such a thing very easily.
Hmm... I OTOH don't think the encoding should be part of the string. The encoding is really external to the string, more like a function that is applied to the string. If you can wrap the string in a UTF-8, UTF-16, UTF-32 encoder/decoder then that should be the way to go. However building it into the string is not something that will scale in case there are other encodings that would be supported -- think about not just Unicode, but things like Base64, Zip, <insert encoding here>. Ultimately the underlying string should be efficient and could be operated upon in a predictable manner. It should be lightweight so that it can be referred to in many different situations and there should be an infinite number of possibilities for what you can use a string for. -- Dean Michael Berris about.me/deanberris