Bug #10924: String#b

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: 2.1.0
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN

[trans (Thomas Sawyer)]

Well, I just learned about the String#b method today. And of course it breaks the Radix gem :-( Honestly, back when I create Radix in 2009 I could not have imagined a safer bet than #b for an extension if I tried. And yet sure enough, Ruby makes String#b an official method for converting to ASCII 8-bit. Is it really such a popular method to get such a short name? I mean String#ascii wouldn't have been a better choice? To go along with #ascii_only?

Okay, so much for my mini-rant. So bottom line, can I ask that this method not be called #b? Even putting the conflict with Radix aside, I think it's a pretty bad name for a standard Ruby method. Just read it: "#b". Do you have any idea what that does without looking it up in the documentation? Nope, no way.

(P.S. Bug or feature, not sure what to label it. Left it a bug b/c it did break people's code.)

[Eregon (Benoit Daloze)]

Note #b is more #binary than #ascii.

[shevegen (Robert A. Heiler)]

I think that, the name aside, this would be a wonderful example for different
namespaces and restoring to the old default afterwards.

That way, you could undefine String#b for the purpose of only your gem alone here
but leave it untouched otherwise.

Just like your code would be in its own little namespace whereas for everywhere
else outside, String#b works fine as it would be.

[trans (Thomas Sawyer)]

Benoit Daloze wrote:

Note #b is more #binary than #ascii.

That at least make a little more sense out of the name #b, but that needs some explanation since every string is actually binary underneath regardless of encoding. (Note the word "binary" is not mentioned at all in the docs.)

[trans (Thomas Sawyer)]

Robert A. Heiler wrote:

I think that, the name aside, this would be a wonderful example for different
namespaces and restoring to the old default afterwards.

That way, you could undefine String#b for the purpose of only your gem alone here
but leave it untouched otherwise.

Just like your code would be in its own little namespace whereas for everywhere
else outside, String#b works fine as it would be.

Refinements scoped at the gem level? I think I argued in favor of that once.

I don't so much mind refinements even at the file level, but I think the special notation made them all but useless. I think refinements need to be something that is imposed by the user and the underlying code itself is unchanged. In other words, give me a file that has a core-extension defined in it. If I say:

require 'core-ext.rb'

Then the core extension is added globally, but if say:

refine 'core-ext.rb'

Then it is the same but only apples locally. The core-ext.rb file itself is the same in either case.

[duerst (Martin Dürst)]

Thomas Sawyer wrote:

Refinements scoped at the gem level? I think I argued in favor of that once.

That turned out to be very difficult to implement.

I don't so much mind refinements even at the file level, but I think the special notation made them all but useless. I think refinements need to be something that is imposed by the user and the underlying code itself is unchanged. In other words, give me a file that has a core-extension defined in it. If I say:

require 'core-ext.rb'

Then the core extension is added globally, but if say:

refine `core-ext.rb`

Then it is the same but only apples locally. The core-ext.rb file itself is the same in either case.

It looks very good to me, and I think it could be implemented fairly easily. I suggest you create a feature for this.

[duerst (Martin Dürst)]

Thomas Sawyer wrote:

Benoit Daloze wrote:

Note #b is more #binary than #ascii.

That at least make a little more sense out of the name #b, but that needs some explanation since every string is actually binary underneath regardless of encoding. (Note the word "binary" is not mentioned at all in the docs.)

irb(main):001:0> Encoding::BINARY
=> #Encoding:ASCII-8BIT

Encoding::BINARY is an alias for Encoding::ASCII-8BIT. Because pure ASCII works well with most other encodings anyway, String#b is mostly used when the binary value (byte for byte rather than character for character) of a string is required.

[duerst (Martin Dürst)]

Thomas Sawyer wrote:

Well, I just learned about the String#b method today. And of course it breaks the Radix gem :-( Honestly, back when I create Radix in 2009 I could not have imagined a safer bet than #b for an extension if I tried.

Essentially, no name is safe. However well you may try, you may have bad luck.

And yet sure enough, Ruby makes String#b an official method for converting to ASCII 8-bit. Is it really such a popular method to get such a short name? I mean String#ascii wouldn't have been a better choice? To go along with #ascii_only?

It's actually short because it's supposed to be syntactic sugar, somewhat similar to the options on a Regexp literal.

Okay, so much for my mini-rant. So bottom line, can I ask that this method not be called #b? Even putting the conflict with Radix aside, I think it's a pretty bad name for a standard Ruby method. Just read it: "#b". Do you have any idea what that does without looking it up in the documentation? Nope, no way.

That's a valid point, but it would also apply to your use of #b in Radix, wouldn't it? It may just be me, but I'd have more of an idea what's going on for
[100,10].base(256).to_a(10)
than for
[100,10].b(256).to_a(10)

[trans (Thomas Sawyer)]

That's the irony. One of the reasons I choose #b is because I thought for sure that would almost certainly never become a conflict in the future. I would expect #base to be a much more likely vector for clashing.

Giving this more thought, maybe it would be better to approach this with a feature request that Ruby incorporate Radix' functionality into Ruby itself. After all, it's pretty basic CS stuff. Then the Ruby core team can fuss about the best API ;)

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Closed

Considering String#b has now been present since Ruby 2.0, and renaming it would break tons of code, I think there is no chance of it being renamed. It looks like Radix has adjusted to it and works with String#b being defined by default.