On Thu, Jan 27, 2011 at 10:05 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Dean Michael Berris wrote:
But why do you need to separate text encoding from encoding in general?
Names are important. I think this discussion would make more progress if Dean's "string" were given another name, like "bytes," and his "view" were named "string" or perhaps "string_view."
Okay, I think I have to divorce the thought of "what a string should be" from the name "string". I like `bytes` but unfortunately it somehow implicitly conveys mutability -- because computers keey reading and writing bytes after all. Maybe a name that denotes immutability would be good. So for lack of a more creative name, I'll call it `istring` which conveys immutability and string semantics.
You have a sequence of bytes (in a string).
That would be a sequence of bytes in a bytes<char>, say.
Or, an istring. ;)
You want to interpret that sequence of bytes in a given encoding (with a view).
You'd interpret the bytes<char> with a string<utf_8>, say.
Well I'd still rather call it a view. :D
Again, where you see a string primarily as a class for handling raw data, that can be interpreted in hundreds of different ways I see primarily string as a class for encoding human readable text.
So what's the difference between a string for encoding human readable text and a string that handles raw data?
There is no difference, but because "string" connotes "human readable text" to most, using a different name for the raw storage class will dissociate that connotation from the raw storage.
Okay, fair enough. :) So now I guess it's just going to be a matter of finding a suitable name for that string of bytes data structure. -- Dean Michael Berris about.me/deanberris