Re: multibyte strings & bucket-of-bytes efficiency under 1.9.0

Hi Murphy,

Literal strings are, by definition, strings of characters, not bytes.
ByteString.new("Literal") would work, of course.
The exact byte sequence that would result would be
determined by the current default encoding.
ByteString.new should also accept
an array of Fixnums as in:

ByteString.new([76, 105, 116, 101, 114, 97, 108])

The point you make about I/O methods requiring/returning
encoded strings is important.

Perhaps sysread and syswrite should be
defined in terms of ByteStrings while
the higher level I/O methods would deal
exclusively with encoded strings.

Recall that there is already a prohibition against
mixing sysread/syswrite access with higher
level I/O methods on any given file.  So,
having those methods work with ByteStrings would
be quite consistent.

I use sysread and syswrite exclusively
when I write machine to machine protocols
because those methods have no strange side effects
due to clever (human) formatting algorithms,
global variables settings, etc.

Certainly, a String#binary method would
be a good idea.  It would return a ByteString.
Perhaps ByteString#encode()  could return an
encoded String.

I'm not so sure about the String.binary! method,
or even force_encoding(nil), for that matter.
Changing a string's encoding "in place" sames to
me to be a violation of basic OO design principles in
that it is essentially a 'C'-style typecast.

Now that I think more about it, perhaps the
class hierarchy should be:

class String < ByteString

After all, Strings add the concept of 
character encoding to old-style ByteStrings.

Oh well, nobody asked me :-)

- brent


-- 
View this message in context: http://www.nabble.com/multibyte-strings---bucket-of-bytes-efficiency-under-1.9.0-tp14528798p14544702.html
Sent from the ruby-core mailing list archive at Nabble.com.