Re: [boost] Interest in super string class?

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-07-05 09:23:44

David Abrahams wrote:
> Jeff Garland <jeff_at_[hidden]> writes:
> 
>> David Abrahams wrote:
>>> Jeff Garland <jeff_at_[hidden]> writes:
>>>
>>>> The fact is, if you look around at the languages people are using
>>>> most for string processing, they offer just as many features as
>>>> super_string and then some.
>>> Try "python -c help(str)"
>> Looks like I'm still missing a couple functions ;-)  
> 
> And by the same measure, you have some extras (no regexps in python
> strings).

True, but for my work I need regex and I've cited other languages where it is 
integrated.

>>>> There are plenty of counter examples: Perl, 
>>> Not sure that's a good example if you're going for readability;  Plus,
>>> it has special operators that help (and could in principle be
>>> implemented as free functions).
>> I thought the c++ was pretty readable.  As for free functions, I'm
>> not opposed, but so far I haven't seen a proposal that makes the
>> code clearer to my eye.
> 
> Well, Shunsuke Sogame's proposed interface (which echoes some work
> Eric Niebler has already done) works pretty well.  I don't think that
> concatenating string operations with '.' is vastly better than using
> '|', and the former comes with some attendant disadvantages that have
> been detailed elsewhere in this thread.

I guess I have yet to be convinced of the supposed disadvantages. 
super_string is just as extensible as basic_string.  I can still take 
advantage of Sunsuke's code.  But, I think there was actually some agreement 
that if we surveyed programmers more would understand form #1 without reading 
the docs then #2.

   1)  s.replace_all(s2, s3)
   2)  replace_all(out(s1), in(s2), in(s3));

Don't get me wrong, I think the new range interface is a major usability 
advance -- well at least for unix programmers. He actually threw me off a bit 
with this example:

  std::string dst(...)
  range_copy(rng|to_upper|to_lower|to_upper, dst);

which didn't make sense (apparently it was a joke).  Still, I'm pretty sure in 
a code reading contest more programmers would understand this:

   dst.to_upper().to_lower().to_upper();

as obviously ridiculous code.

>>>> Java, Javascript, and Ruby that build regex directly into the
>>>> library/language.
>>> Whoa there.  Python builds regex directly into the library too.  That
>>> doesn't mean it should be part of the string.
>>>
>>>         python -c "import sre;help(sre)"
>> I wasn't trying to suggest that Python didn't support regex.  
> 
> Didn't think you were; you seem to be missing my point, which is that
> there are lots of ways to get the functionality into the library.  It
> doesn't necessarily have to be directly attached to the string class.

No, I got it, but I don't know what to do with it.  Python chose to leave it 
out of the string class -- Java chose to provide a simplified interface(just 
to be clear, there's a Pattern class in JAVA that works with string). In Perl 
it's helped along by language features, but it's essentially built-in using 
operators.  So it's a mixed bag as far as how people have chosen to build 
these functions. Overall though, I didn't see the motivation for leaving Regex 
out if I'm going to add other functions to the string type.  There's no user 
cost if they don't use Regex other then processing of a few extra includes on 
compile.  So my take is that it's confusing to introduce a new string type and 
then make half the functions free functions.  And some of the regex functions 
are 3 parameter case discussed above.

>>>> It's very powerful and useful in my experience.  And, of course,
>>>> super_string doesn't take away anything, just makes these powerful
>>>> tools more accessible and easier to use.
>>> I agree with the idea in principle; I just want to scrutinize its
>>> execution a bit before we all buy into it as proposed ;-)
>> How does that phrase go...it'll be a cold summer day in Az (a balmy
>> 105 now) before we 'all' agree ;-)
> 
> Seems like you're deflecting rather than engaging, which is
> disappointing.  There are lots of important questions here; I'm glad
> you proposed this interface and thereby raised them.  I just wish we
> could have a more complete exploration of the solution space, which --
> especially where C++ is concerned -- is still largely uncharted.

I think I've been plenty engaged.  And we can explore the solutions all we 
want.  It's just a fact that there's some group of people that will never 
agree with me.

Jeff