Symbol#re_s

Ruby
1

Came up with a great little extension today for the Symbol class. One
that also shows off Facets’ Functor class:

require ‘facets/functor’

class Symbol

# Convert symbol to string, apply string method
# and convert back to symbol via a fluent
# interface.
#
#   :HELLO.re_s.downcase  #=> :hello
#
def re_s
  @re_s ||= Functor.new do |op, *a|
    to_s.send(op, *a).to_sym
  end
end

end

I picked the name ‘re_s’ off the top of my head. I’m open to better
suggestions.

T.

2

Thomas S. wrote:

Came up with a great little extension today for the Symbol class. One
that also shows off Facets’ Functor class:

require ‘facets/functor’

class Symbol

# Convert symbol to string, apply string method
# and convert back to symbol via a fluent
# interface.
#
#   :HELLO.re_s.downcase  #=> :hello
#
def re_s
  @re_s ||= Functor.new do |op, *a|
    to_s.send(op, *a).to_sym
  end
end

end

I picked the name ‘re_s’ off the top of my head. I’m open to better
suggestions.

T.

Nice idea. After some modification (using method_missing) it could be
used as a temporary patch on Ruby 1.8, as in Ruby 1.9 symbols are going
to respond to most string-like methods.

also T.

3

On Sep 20, 11:25 am, “Thomas B.” [email protected] wrote:

Nice idea. After some modification (using method_missing) it could be
used as a temporary patch on Ruby 1.8, as in Ruby 1.9 symbols are going
to respond to most string-like methods.

I’m curious to see which methods. But I take it just some methods have
been added, no type of inheritance is going on, right? Ie. If we
extend String, it won’t effect Symbol in any way. Or is there some
magic going on in 1.9 here?

T.

4

Hi –

On Sun, 21 Sep 2008, Trans wrote:

magic going on in 1.9 here?

(Symbol.instance_methods(false) &
String.instance_methods(false)).sort
=> [:<=>, :==, :=~, :[], :capitalize, :casecmp, :downcase, :empty?,
:encoding, :inspect, :intern, :length, :match, :next, :size, :slice,
:succ, :swapcase, :to_s, :to_sym, :upcase]

Symbol.ancestors
=> [Symbol, Comparable, Object, Readline, Kernel, BasicObject]

String.ancestors
=> [String, Comparable, Object, Readline, Kernel, BasicObject]

David

5

Thomas B. wrote:

Thomas S. wrote:

Came up with a great little extension today for the Symbol class. One
that also shows off Facets’ Functor class:

require ‘facets/functor’

class Symbol

# Convert symbol to string, apply string method
# and convert back to symbol via a fluent
# interface.
#
#   :HELLO.re_s.downcase  #=> :hello
#
def re_s
  @re_s ||= Functor.new do |op, *a|
    to_s.send(op, *a).to_sym
  end
end

end

I picked the name ‘re_s’ off the top of my head. I’m open to better
suggestions.

T.

Nice idea. After some modification (using method_missing) it could be
used as a temporary patch on Ruby 1.8, as in Ruby 1.9 symbols are going
to respond to most string-like methods.

also T.

why not simply use:

irb(main):002:0> :HELLO.to_s.downcase.to_sym
=> :hello

6

On Sep 21, 9:33 pm, Stephen C. [email protected] wrote:

=> :hello
class Symbol
def method_missing(*args, &block)
to_s.send(*args, &block).to_sym rescue super(*args, &block)
end
end

True, we can do this. And it sure is convenient, but this approach is
generally frowned upon because it can cover-up actual errors. But in
this case, maybe it’s not significant? What do others think?

T.

7

Hi,

On Sep 21, 2008, at 8:12 PM, Bernard K. wrote:

Convert symbol to string, apply string method

to respond to most string-like methods.

also T.

why not simply use:

irb(main):002:0> :HELLO.to_s.downcase.to_sym
=> :hello

What fun is a new version if you can’t even re-factor?

irb(main):001:0> RUBY_VERSION
=> “1.9.0”
irb(main):002:0> :test.capitalize
=> :Test

A 1.8.x patch needn’t rely on Facets, however:

class Symbol
def method_missing(*args, &block)
to_s.send(*args, &block).to_sym rescue super(*args, &block)
end
end

Stephen

8

Hi,

On Mon, Sep 22, 2008 at 8:02 AM, Trans [email protected] wrote:

True, we can do this. And it sure is convenient, but this approach is
generally frowned upon because it can cover-up actual errors. But in
this case, maybe it’s not significant? What do others think?

Some frown upon monkey-patching, some frown upon blind rescues, but the
fact
that we have them at our side is nice.

In this case, everything will be re-raised by the symbol if
String#instance_method doesn’t return something that can be sent
“to_sym”.

However, I agree with TPR, and that as far as maintainable code goes,
things
should be manifest.

Stephen

9

On Sep 22, 9:09 am, “Thomas B.” [email protected] wrote:

I think that it’s a better idea to have a constant table with names of
methods that should be ported from String to Symbol, and compare the
missing method’s name against this table.

That limits the utility too much, because then one can’t extend String
and have Symbol just work too.

I like the method_missing idea, but I fear it is slightly too
dangerous to make a standard behavior. Unless someone proves my fears
to be unfounded, then using something like #re_s is the safe bet.

T.

10

Thomas S. wrote:

On Sep 21, 9:33�pm, Stephen C. [email protected] wrote:

=> :hello
� �class Symbol
� � �def method_missing(*args, &block)
� � � �to_s.send(*args, &block).to_sym rescue super(*args, &block)
� � �end
� �end

True, we can do this. And it sure is convenient, but this approach is
generally frowned upon because it can cover-up actual errors. But in
this case, maybe it’s not significant? What do others think?

T.

I think that it’s a better idea to have a constant table with names of
methods that should be ported from String to Symbol, and compare the
missing method’s name against this table.

TPR.