From: Austin Ziegler <halostatue@...>
Date: 2006-06-26T11:42:38+09:00
Subject: Re: Unicode roadmap?

On 6/25/06, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> In message "Re: Unicode roadmap?" on Mon, 26 Jun 2006 10:22:15 +0900,
> "Phillip Hutchings" <sitharus@sitharus.com> writes:
>|>   st = File.open("file.txt", "rb") { |f| f.read_string }
>|>   bv = File.open("file.txt", "rb") { |f| f.read_bytes }
>| Why? This looks needlessly complex.
>|
>| string = File.open('file.txt', 'r') {f.read.to_s(:utf-8)}
>|
>| Or possibly
>| string = File.open('file.txt', 'r') {f.read(:utf8)}
>| bytes = File.open('file.txt', 'r') {f.read(:bytearray)}
> They are equally more complex than the current design.  If File can
> return String or ByteArray, why shouldn't String with "no encoding"
> behave as sequence of bytes instead of separating?  Are there any
> specific operations that should be in ByteArray but not in String, or
> vise versa?

There are operations for Strings (#each_character, perhaps) that make
less sense for ByteVectors than for character-based Strings. But
everything or nearly everything you would want to do with a ByteVector
you would want to do with a String, and some operations from Strings
make sense on ByteVectors (regexp operations).

I would much rather keep the API -- and the class library -- simple. I
would rather do this:

  st = File.open("file.txt", "rb", :encoding => :utf8) { |f| f.read }

or

  bv = File.open("file.txt", "rb") { |f| f.read }
  st = bv.to_encoding(:utf8)

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca