Feature #7849
Symbol#to_str
Added by trans (SYSTEM ERROR) about 1 month ago. Updated 12 days ago.
| Status: | Rejected | Start date: | 02/14/2013 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | core | |||
| Target version: | next minor |
Description
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.
History
[ruby-core:52237]#1
Updated by Student (Nathan Zook) about 1 month ago
Bad idea. to_str should only be defined on things that really are Strings, and Symbol are most definitely not Strings.
I agree that Symbol is unusually close to String. If, for your needs, you were to define to_st on String & on Symbol, you could have the utility you desire.
[ruby-core:52241]#2
Updated by trans (SYSTEM ERROR) about 1 month ago
> If, for your needs, you were to define to_st on String & on Symbol, you could have the utility you desire.
Yes, I thought about that. But concluded it was most likely unnecessary complexity when #to_str would work fine.
You say "Bad idea". But show me why it is bad idea other then "them's the rules". I tried to think of a problem case, and the only one I can think of is using `foo.respond_to?(:to_str)` to identify Stringy things and very specifically not meaning to include Symbols. It's possible, but it's a fairly narrow proposition. Not the least reason being that one should never use `respond_to?` if one does not need to b/c it is a fragile approach. But more significantly, what is more likely to be used? This narrow usecase or Symbol#to_str? Clearly the later by far. And the former is easily solved with `&& !Symbol === foo`.
[ruby-core:52243]#3
Updated by charliesome (Charlie Somerville) about 1 month ago
Symbols are not Strings. I'm afraid this would only serve to blur the line even more.
Rubyists need to stop using Symbols where they actually want a String, and vice versa.
Strong -1 from me.
[ruby-core:52247]#4
Updated by drbrain (Eric Hodel) about 1 month ago
- Status changed from Open to Rejected
You cannot gsub, enumerate characters in or alter encoding of a Symbol, so it is not a string representation.
[ruby-core:52286]#5
Updated by trans (SYSTEM ERROR) about 1 month ago
> 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?
[ruby-core:52287]#6
Updated by trans (SYSTEM ERROR) about 1 month ago
@charliesome Actually, that's exactly what my proposal attempts to address. You don't always have a choice in what type of object you receive, but you want it to become a string. Consider a DSL like Rake's. One could use:
task :foo do ...
Or
task 'foo' do ...
Either one is acceptable, and I think it would be overreaching to make people not be able to use a symbol here.
On the other hand do we want any object to be acceptable? B/c just about every object responds to #to_s. To avoid this, you would end up with something like: (WARNING! Fugly code ahead.)
def task(name) name = (Symbol === name ? name.to_s : name.to_str) ... end
There has to be a clearer solution than that.
P.S. Just for fun of it I tried this on rake and discovered the Jim decided not to care what get's passed to task. Try this in your Rakefile:
desc "OMG!" task Object.new do puts "OMG is right!" end
A Duck-typing true beleiver!!! Yea, looks like a bug to me. If the user really needs it they can call #to_s.
[ruby-core:52294]#7
Updated by drbrain (Eric Hodel) about 1 month ago
The purpose of to_str, to_int, to_ary and to_sym are to convert string, integer, array and symbol representations to objects of that class.
For example:
The rope data structure (which supports insertion, deletion and random access) can be used to implement a representation of a ruby string so it would be a good candidate for to_str.
A linked-list implementation could be a good candidate for to_ary
A roman numeral implementation that does not descend from Numeric represents an integer and would be a good candidate for to_int
A string can be used as an identifier (as in rake) so it has to_sym.
A symbol, being an identifier alone is not anything like a String.
[ruby-core:53176]#8
Updated by trans (SYSTEM ERROR) 12 days ago
Symbol's not anything like a Proc either, but we have Symbol#to_proc.
Put that in your pipe and smoke it ;-)
Also available in: Atom PDF