Something that would work instead of a StringPool that is Ruby-ish is use of symbols. Symbols are Ruby's answer to the StringPool. If things are stored as symbols, you can work with them similarly as to what you would expect and reduce # objects, e.g.
jruby-1.7.0.preview2 :008 > :error.object_id
=> 2050
jruby-1.7.0.preview2 :009 > :error.object_id
=> 2050
jruby-1.7.0.preview2 :010 > :error.to_s.chomp!('or').to_sym
=> :err
jruby-1.7.0.preview2 :011 > :error.to_s.chomp!('or').to_sym.object_id
=> 2052
jruby-1.7.0.preview2 :012 > :error.to_s.chomp!('or').to_sym.object_id
=> 2052
So basically if everywhere in Rails documentation that referred to strings instead specified constants, and if the method didn't support constants that would be a good goal:
http://guides.rubyonrails.orgBut still, whenever you output a string to a log, it becomes a string. So, you might be able to make some inroads by changes to Rails and related documentation, but if Ruby "fixed it" instead via something like StringPool (again- a major and breaking change), then you wouldn't have to worry about wasting all that time on the Rails side.
In addition, many text editors and IDEs have different colors for Strings, so that keys and values stand out better in examples like:
class Employee < ActiveRecord::Base
has_many :subordinates, :class_name => "Employee",
:foreign_key => "manager_id"
belongs_to :manager, :class_name => "Employee"
end
So, if you switch to all symbols, it is a little more monotone, colorwise. However, if you switch to Ruby 1.9 key/value then you could color the key in a: :b differently by the fact that it ends in a colon vs. starting with one. Unfortunately, the existing default color schemes don't usually do that.