On Fri, Dec 31, 2010 at 12:14, Nikolai Weibull <now / bitwi.se> wrote:
> On Fri, Dec 31, 2010 at 03:09, Nobuyoshi Nakada <nobu / ruby-lang.org> wrote:
>> Hi,
>>
>> At Fri, 10 Dec 2010 00:34:35 +0900,
>> Nikolai Weibull wrote in [ruby-core:33648]:
>>> IO implements #freeze, but StringIO doesn. What¡Çs up with that?
>>
>> What do you mean? IO#freeze does not exist, but just is inherited
>> from Kernel, and also StringIO.
>
> Sorry if I was unclear. IO objects runs rb_check_frozen for most
> methods before they actually do anything, while StringIO doesn¡Çt.

I now see that certain methods check whether the internal String is
frozen and then raise an IOError.  You can thus use
StringIO.new("abc").string.freeze to freeze part of the StringIO.

Anyway, what I really want to know now is, would it be desirable by
anyone other than me that, for example, StringIO#rewind raise
TypeError if the StringIO is frozen?  Or is it even the case that such
behavior is undesirable?

The more I think about it, why is the IO code not more modularized?
Why do we need a completely separate implementation of IO where the
¡Èbase¡É object is a String?  At least for the output part oft, it
seems that implementing #write would be sufficient to include a module
containing methods like #putc, #print, #puts, #printf, and similar.
Most of this would be true for reading as well, if a proper interface
was defined.

Perhaps we don¡Çt need something as ¡Èadvanced¡É as

http://library.gnome.org/devel/gio/stable/streaming.html

but it seems to me that there is an opportunity for simplification here.