Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-28 04:20:44

On Thu, Jan 27, 2011 at 11:09 PM, Matus Chochlik <chochlik_at_[hidden]> wrote:
> On Thu, Jan 27, 2011 at 2:55 PM, Dean Michael Berris
> <mikhailberis_at_[hidden]> wrote:
>>
>> Usability of what, the type? Any type is as usable as any other the
>> way I see it -- they're all just types. So aside from
>> aesthetic/cosmetic differences, what's the point?
>
> I don't want to sound like an advertisment but ..
> aesthetic matters .. to many people. Unless we want
> to turn even the completely basic things into rocket
> science.
>

I don't know who advertises and says "aesthetics matter" -- because I
don't see advertisements that say that; they imply it though, but not
straight out say it. But that's beside the point. :D

I don't know what you mean by "completely basic things". Are you
referring to string processing? Because there's a programming language
out there precisely for dealing with strings (called Perl) and I'd say
that's far from basic.

>>
>> What verbosity?
>
> Like in having to say to much (view<some_encoding_3>)
> to express a very simple thing (string/text)?
>

That's what typedefs are for -- you can call it anything you like.

>>
>> Well:
>>
>> typedef boost::strings::view<boost::strings::utf8_encoding> utf8_string;
>
> This (well not exactly utf8_string, but that was a completely
> different discussion) is what I was suggesting all along :)
>

So why is it not exactly utf8_string? It's a view of a string that has
a UTF-8 encoding.

>>
>> struct person {
>> Â utf8_string name, middle_name, family_name;
>> };
>>
>> Where's the verbosity in that?
>
> Chop away the utf8_ part and I will be happy and quiet.
>

Unfortunately, that's not what a string is IMO. A string *again*
doesn't have a default encoding and an encoding is not part of the
definition of a string -- which I have already maintained earlier on.

>>
>> I don't know what "acceptability" and "adoptability" mean in this context.
>
> It is the "sex-appeal" of your class.

Weh?

> It is basically about if
> the people would be willing to take your class and use it
> instead of std::string in their code and this includes
> doing all the necessary changes in their code.
>

So that's not really anything about me or my string, but more about
users. Right? Beauty *is* in the eye of the beholder while quality is
something we all understand but yet have a hard time defining. So I'd
rather strive for quality than beauty. And if it's high quality enough
then making people switch would be a matter of choice on their end.
Right?

>>
>> Backward compatibility to a broken implementation hardly seems like a
>> worthy goal. Deprecation is a better route IMHO.
>
> OK, so what do you propose your string is going
> to be called in the standard? Because calling
> it std::string is not deprecation. Deprecation would
> be calling it std::someotherstring and having them
> both in the standard for a certain period of time.
>

You can deprecate the interface of std::string. This is what I've been
saying all along. Once you deprecate string mutation, then you end up
with an interface thats similar to what I had been proposing. And at
that point, the idea would have ultimately won.

>>
>> Even if it does become std::string, it will be a deprecation of the
>> original definition. Deprecation *is* an option.
>>
>
> OK, if it is called std::string how do you imagine this would
> work? The (old) std::string would be deprecated for a certain
> period of time and then it would be replaced by (new) std::string ?
>

Nope, in the transition period it would say that the mutations are
actually deprecated, remove them now or it will break in the next
upcoming standard.

> If this is what you have in mind then I need to change my
> view on what that word means.
>

You can deprecate the current notion of std::string -- the underlying
implementation can change once a new standard is ratified, and like
shared_ptr<> if it's already in boost, will probably be adopted by
compiler vendors with their specific enhancements for their compiler.

If that's not what deprecation means I don't know any other meaning of it.

HTH

-- 
Dean Michael Berris
about.me/deanberris