Issue #5479 has been updated by Nobuyoshi Nakada.

Status changed from Open to Rejected

You propose two different feature requests at once.

I reject the first one, "import StringIO into core", because it doesn't seem necessary.

I'm considering the second one.
----------------------------------------
Feature #5479: import StringIO into core, add String#to_io
http://redmine.ruby-lang.org/issues/5479

Author: Konstantin Haase
Status: Rejected
Priority: Normal
Assignee: 
Category: 
Target version: 2.0


Currently, a lot of APIs accept both String and IO instances. To differentiate what has been handed to those methods, the code often checks the object's class. However, from statements made by Matz at this years RubyConf it became clear that you should not rely on classes as contracts. Often, these projects wrap the String in a StringIO to avoid having two internal implementations.

It would be useful to add StringIO to core. This would allow adding a #to_io method to String (IO already implements #to_io).

An example use case:

WEBrick is one of those projects checking an objects class. Currently it is not possible to use Rails template streaming or the Sinatra streaming API with WEBrick, the de facto default server for both projects. If strings would implement #to_io, WEBrick would simply have to call #to_io on this. Rack/Sinatra/Rails could simply return an object that responds #to_io and in turn returns an object that behaves like IO, since creating a proper IO subclass that behaves properly and does not have a file handler is rather hard, especially if you want to support multiple Ruby versions (hence StringIO not inheriting from IO).



-- 
http://redmine.ruby-lang.org