On Thu, Jan 27, 2011 at 11:09 PM, Matus Chochlik <chochlik@gmail.com> wrote:
On Thu, Jan 27, 2011 at 2:55 PM, Dean Michael Berris <mikhailberis@gmail.com> 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