Re: Unibyte characters, strings, and buffers

[Stephen J. Turnbull]

David Kastrup writes:
 > "Stephen J. Turnbull" <address@hidden> writes:

 > > But this is a completely different issue from unibyte buffers.  Emacs
 > > doesn't need unibyte buffers to perform its work, and if they are
 > > desirable on the grounds of space or time efficiency, they should be
 > > opaque to Lisp.
 > 
 > Well, Emacs is more following the non-opaque philosophy (XEmacs, in
 > contrast, has even an opaque character type and several other
 > ones).

Those are irrelevant to my point, though.

The problem here is that unibyte buffers are a second representation
of a single type (the buffer).  "Mr. Foot, meet Mr. Bullet, I'm sure
you'll get along fine!"

 > That has the advantage that you can use all sorts of available tools as
 > long as they don't break.

In this case, it's like being offered the hammer head and the handle
separately.  I'll say one thing for that approach, though -- now you
have *two* excellent ways to give yourself a headache, with two
different (musical?) sounds when you drum on your crown!

 > It has the disadvantage that the question "what is the right behavior
 > for x?"  needs to be answered quite more often since you can't take the
 > "x does not apply to y anyway" route out as often.

The right behavior here is for a unibyte buffer to do *exactly* the
same thing that a multibyte buffer would.  In which case you have a
single (opaque) type, as far as users can tell.

 > Efficiency took a dive but the alternatives were just too horrible
 > API-wise.

Unibyte buffer is just too horrible API-wise.  My advice is: nuke it.

Steve