Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-27 09:25:19

On Thu, Jan 27, 2011 at 10:05 PM, Stewart, Robert
<Robert.Stewart_at_[hidden]> 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