From: Michael Selig <michael.selig@...>
Date: 2008-10-10T17:03:40+09:00
Subject: [ruby-core:19271] Re: default_internal for CSV (was Re: Re:default_internal encoding)

On Fri, 10 Oct 2008 18:23:13 +1100, Martin Duerst <duerst@it.aoyama.ac.jp>  
wrote:

> However, there was discussion on ruby-dev to provide some
> method that would do
>     default_internal || default_external
> internally, so that programmers could just use a single call.
> Unfortunately, I don't know yet what this will be called.

My preference would actually be that default_internal is always set, so  
such a beast would not be needed.

However, given the apparent opposition to this idea, I would suggest that  
libraries NOT do any transcoding if default_internal is nil, putting the  
burden on the programmer to ensure that encodings are all compatible. This  
not only makes libraries easier to implement, but more efficient also.  
This burden would only be felt by programs that deal with multiple  
encodings *and* that choose not to set default_internal - a small  
percentage I would think.

If all libraries are going to transcode to "default_external" when  
"default_internal" is not set, then it seems to defeat the whole reason  
for introducing default_internal in the first place. CSV is a good example  
- it now transcodes everything (because at the time of patching to support  
encodings there was no other option), so default_internal actually  
provides no benefit to it (and in fact is a bit of an annoyance!)

This means that there should be little use for something that does  
"default_external || default_internal" (in libraries anyhow).

What *would* be very handy is a method like String#encode_internal, which  
would implement something like:

	Encoding.default_internal ? s.encode(Encoding.default_internal) : s

This would be very useful when returning strings from "encoding aware"  
libraries.

Cheers
Mike