Project

General

Profile

Actions

Feature #5678

closed

StringIO#to_str

Feature #5678: StringIO#to_str

Added by MartinBosslet (Martin Bosslet) almost 14 years ago. Updated almost 14 years ago.

Status:
Closed
Target version:
[ruby-core:41340]

Description

The following raises an error currently:

require 'stringio'
require 'openssl'

io = StringIO.new(OpenSSL::ASN1::Integer.new(1).to_der)
asn = OpenSSL::ASN1.decode io

The reason is that ossl_obj2bio[1] looks for a
T_FILE first, and then it tries to coerce the
input to a String using StringValue. StringValue
itself again expects the presence of to_str,
which is currently missing for StringIO, but
could be easily provided by aliasing
StringIO#string.

I could imagine that the heuristic of ossl_obj2bio
is quite common when working on binary data in a
C extension. Would it therefore be OK to add
StringIO#to_str? Patch attached.

[1] https://github.com/ruby/ruby/blob/trunk/ext/openssl/ossl_bio.c#L17


Files

stringio.patch (582 Bytes) stringio.patch MartinBosslet (Martin Bosslet), 11/28/2011 09:52 AM

Updated by nobu (Nobuyoshi Nakada) almost 14 years ago Actions #1 [ruby-core:41345]

  • Status changed from Open to Feedback

Martin Bosslet wrote:

The following raises an error currently:

require 'stringio'
require 'openssl'

io = StringIO.new(OpenSSL::ASN1::Integer.new(1).to_der)
asn = OpenSSL::ASN1.decode io

Why do you need to pass `io', not io.string or the result of to_der?

Updated by MartinBosslet (Martin Bosslet) almost 14 years ago Actions #2 [ruby-core:41347]

Nobuyoshi Nakada wrote:

Martin Bosslet wrote:

The following raises an error currently:

require 'stringio'
require 'openssl'

io = StringIO.new(OpenSSL::ASN1::Integer.new(1).to_der)
asn = OpenSSL::ASN1.decode io

Why do you need to pass `io', not io.string or the result of to_der?

I don't really need to, it's just that I am working on making
ASN1.decode streaming-aware. So I wanted it to work with any
IO or IO-like object and additionally with Strings. That's why
I thought if someone passes a StringIO, they would be surprised
if an error was raised - they passed an IO-like object after all
and there is no apparent reason why this shouldn't work.

I could, however, call StringIO#string as you suggested, but
I would prefer to use StringValue, as a more generic way
of coercing things into Strings. And it would potentially work
for a wider variety of objects, not only limited to StringIO.

Do you see any negative aspects when adding StringIO#to_str?

Updated by matz (Yukihiro Matsumoto) almost 14 years ago Actions #3 [ruby-core:41352]

Hi,

In message "Re: [ruby-core:41347] [ruby-trunk - Feature #5678] StringIO#to_str"
on Mon, 28 Nov 2011 11:16:33 +0900, Martin Bosslet writes:

|Do you see any negative aspects when adding StringIO#to_str?

Yes, to_str should be implemented for objects that have (almost) same
method signature as strings, which is not true for StringIO.

						matz.

Updated by MartinBosslet (Martin Bosslet) almost 14 years ago Actions #4 [ruby-core:41354]

  • Status changed from Feedback to Closed

Yukihiro Matsumoto wrote:

Hi,

In message "Re: [ruby-core:41347] [ruby-trunk - Feature #5678] StringIO#to_str"
on Mon, 28 Nov 2011 11:16:33 +0900, Martin Bosslet writes:

|Do you see any negative aspects when adding StringIO#to_str?

Yes, to_str should be implemented for objects that have (almost) same
method signature as strings, which is not true for StringIO.

  					matz.

OK, thank you for clarifying this! I will use StringIO#string then.

Updated by now (Nikolai Weibull) almost 14 years ago Actions #5 [ruby-core:41355]

On Mon, Nov 28, 2011 at 07:16, Yukihiro Matsumoto wrote:

In message "Re: [ruby-core:41347] [ruby-trunk - Feature #5678] StringIO#to_str"
   on Mon, 28 Nov 2011 11:16:33 +0900, Martin Bosslet writes:

|Do you see any negative aspects when adding StringIO#to_str?

Yes, to_str should be implemented for objects that have (almost) same
method signature as strings, which is not true for StringIO.

How about implementing #to_s instead?

Updated by matz (Yukihiro Matsumoto) almost 14 years ago Actions #6 [ruby-core:41356]

Hi,
In message "Re: [ruby-core:41354] [ruby-trunk - Feature #5678][Closed] StringIO#to_str"
on Mon, 28 Nov 2011 18:50:12 +0900, Martin Bosslet writes:

|OK, thank you for clarifying this! I will use StringIO#string then.

At the same time, having ASN1.decode to treat T_FILE but not StringIO
is against duck typing. I think it is better if we can do something.
But I don't have a good idea yet. #to_io does not work here. #to_str
is not appropriate.

						matz.

Updated by MartinBosslet (Martin Bosslet) almost 14 years ago Actions #7 [ruby-core:41378]

Yukihiro Matsumoto wrote:

Hi,
In message "Re: [ruby-core:41354] [ruby-trunk - Feature #5678][Closed] StringIO#to_str"
on Mon, 28 Nov 2011 18:50:12 +0900, Martin Bosslet writes:

At the same time, having ASN1.decode to treat T_FILE but not StringIO
is against duck typing. I think it is better if we can do something.
But I don't have a good idea yet. #to_io does not work here. #to_str
is not appropriate.

  					matz.

We could handle StringIO exceptionally by trying to call #string on the
object passed. But that's not too elegant and will probably only work in
the very specific case of StringIO. Implementing #to_s like Nikolai
suggested could be another solution? Then we could apply the following
heuristic that should cover almost any (valid) case:

  1. check for T_FILE
  2. try #to_str
  3. try #to_s ?
Actions

Also available in: PDF Atom