Ruby trunk - Feature #7849: Symbol#to_str</h1> <article> <h1>Ruby trunk - Feature #7849: Symbol#to_str</h1> <p>2013-02-14T09:49:25Z</p> <ul></ul><p>Bad idea. to_str should only be defined on things that really are Strings, and Symbol are most definitely not Strings.</p> <p>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.</p> </article> <article> <h1>Ruby trunk - Feature #7849: Symbol#to_str</h1> <p>2013-02-14T10:14:53Z</p> <ul></ul><blockquote> <p>If, for your needs, you were to define to_st on String & on Symbol, you could have the utility you desire.</p> </blockquote> <p>Yes, I thought about that. But concluded it was most likely unnecessary complexity when #to_str would work fine.</p> <p>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 <code>foo.respond_to?(:to_str)</code> 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 <code>respond_to?</code> 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 <code>&& !Symbol === foo</code>.</p> </article> <article> <h1>Ruby trunk - Feature #7849: Symbol#to_str</h1> <p>2013-02-14T10:36:37Z</p> <ul></ul><p>Symbols are not Strings. I'm afraid this would only serve to blur the line even more. </p> <p>Rubyists need to stop using Symbols where they actually want a String, and vice versa.</p> <p>Strong -1 from me.</p> </article> <article> <h1>Ruby trunk - Feature #7849: Symbol#to_str</h1> <p>2013-02-14T13:08:50Z</p> <ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Rejected</i></li></ul><p>You cannot gsub, enumerate characters in or alter encoding of a Symbol, so it is not a string representation.</p> </article> <article> <h1>Ruby trunk - Feature #7849: Symbol#to_str</h1> <p>2013-02-15T21:24:37Z</p> <ul></ul><blockquote> <p>You cannot gsub, enumerate characters in or alter encoding of a Symbol, so it is not a string representation.</p> </blockquote> <p>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 <em>is no</em> absolute interface that dictates their proper use. As long the method returns the expected type then its purely a question of <em>practicality</em>. And I submit that Symobol#to_str is about a practical as it gets.</p> <p>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.</p> <p>I think you rejected this issue far too prematurely. Do you guys even know the purpose of dialog?</p> </article> <article> <h1>Ruby trunk - Feature #7849: Symbol#to_str</h1> <p>2013-02-15T21:58:02Z</p> <ul></ul><p>=begin<br> @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:</p> <pre>task :foo do ... </pre> <p>Or</p> <pre>task 'foo' do ... </pre> <p>Either one is acceptable, and I think it would be overreaching to make people not be able to use a symbol here. </p> <p>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.)</p> <p>def task(name)<br> name = (Symbol === name ? name.to_s : name.to_str)<br> ...<br> end</p> <p>There has to be a clearer solution than that.</p> <p>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:</p> <pre>desc "OMG!" task Object.new do puts "OMG is right!" end </pre> <p>A Duck-typing true beleiver!!! Yea, looks like a bug to me. If the user really needs it they can call #to_s.<br> =end</p> </article> <article> <h1>Ruby trunk - Feature #7849: Symbol#to_str</h1> <p>2013-02-16T04:55:39Z</p> <ul></ul><p>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.</p> <p>For example:</p> <p>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.</p> <p>A linked-list implementation could be a good candidate for to_ary</p> <p>A roman numeral implementation that does not descend from Numeric represents an integer and would be a good candidate for to_int</p> <p>A string can be used as an identifier (as in rake) so it has to_sym.</p> <p>A symbol, being an identifier alone is not anything like a String.</p> </article> <article> <h1>Ruby trunk - Feature #7849: Symbol#to_str</h1> <p>2013-03-07T10:05:34Z</p> <ul></ul><p>Symbol's not anything like a Proc either, but we have Symbol#to_proc.</p> <p>Put that in your pipe and smoke it ;-)</p> </article> </main></body></html>