From: "trans (Thomas Sawyer)" Date: 2013-02-15T21:24:38+09:00 Subject: [ruby-core:52286] [ruby-trunk - Feature #7849] Symbol#to_str Issue #7849 has been updated by trans (Thomas Sawyer). > You cannot gsub, enumerate characters in or alter encoding of a Symbol, so it is not a string representation. That the official spec on the definition of a Stringy-thing? That's the "problem" with #to_str, #to_ary, etc. isn't it? There *is no* absolute interface that dictates their proper use. As long the method returns the expected type then its purely a question of *practicality*. And I submit that Symobol#to_str is about a practical as it gets. And let me put it another way. If you inherited some code that relied on an object responding to #to_str to ensure it also responded to #gsub, #map and #force_encoding (which is the crux of your "definition"), what would you think? Yes, you'd have seriously fragile code on your hands and you'd be a'fixing it. I think you rejected this issue far too prematurely. Do you guys even know the purpose of dialog? ---------------------------------------- Feature #7849: Symbol#to_str https://bugs.ruby-lang.org/issues/7849#change-36317 Author: trans (Thomas Sawyer) Status: Rejected Priority: Normal Assignee: Category: core Target version: next minor Even though a Symbol is not technically an honest-to-goodness String, from the standpoint of simple practicality it would help to have Symbol#to_str defined. There are times when we want an argument to accept a String or a Symbol, but don't really want it to accept any type of object under the sun that responds to #to_s --which is just about anything. This is especially the case when writing DSLs. Having Symbol#to_str is the nice solution to this. Defining Symbol#to_str may be an exception to the rule, but it's one worth making. -- http://bugs.ruby-lang.org/