Re: strbuf API

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sep 3, 2007, 12:29 UTC
Message-ID: <Pine.LNX.4.64.0709031322260.28586@racer.site>
In-Reply-To: <7vejhgksza.fsf@gitster.siamese.dyndns.org>

Hi,

On Mon, 3 Sep 2007, Junio C Hamano wrote:

Show 23 quoted lines

> Pierre Habouzit <madcoder@debian.org> writes:
> 
> > On Mon, Sep 03, 2007 at 08:32:16AM +0000, Matthieu Moy wrote:
> >>  ...
> >> For example, it would be very tempting to compare files with
> >> "strcmp(buf1, buf2)", but that would just fail silently when the file
> >> contains a '\0' byte.
> >
> >   Indeed, OTHO doing that would be pretty silly, as embending NULs in a
> > strbuf is wrong, it's a _str_buf, not a random-binary-buffer. It's meant
> > to make the use of strings easier, not to use as generic purpose byte
> > buffers. Of course they can, but well, it's not what they are designed
> > for in the first place.
> 
> People, please realize strbuf "API" is not a serious API.  
> 
> It wasn't even intended to be anything more than just a
> quick-and-dirty implementation of fgets that can grow
> dynamically.  The other callers added by people to have it do
> general string manipulations were just bolted-on, not designed.
> I haven't taken a serious look at bstring nor any of the
> alternatives yet, but defending strbuf as if it was designed to
> be a sane API is just silly.

Two points:

- it can be turned into an API (pretty easy, really, since it is _really_ 
  small), and

- it is easy to hack on, because it is _not_ a full-blown cover-them-all 
  library.  As such, we can tweak it the way _we_ want.  And if that means 
  that we do not NUL terminate, so be it.  And if that means that we turn 
  it into a rope structure, so be it.

IOW it might be utterly incomplete, but at least it can evolve in a manner that we like. It does not need to be a *kaboom-here-we-have-a-big-dump*.

I know that we had something like that with LibXDiff. I was not particularly happy with the process, but it turned out quite well, as Davide helped us a lot.

But the diff situation is completely different from the string situation:

- we did not have _anything_ in the way of diff generation,

- it is pretty well defined what a diff generation library should do, and

- diff generation is not trivial, and it would have taken us quite a long 
  time to write it ourselves.

All three points are not true with string manipulation.

But code talks, and as I do not have anything presentable (yet), I'll just shut up, until I have.

Ciao, Dscho