From: Dick Davies Date: 2004-04-05T07:44:59+09:00 Subject: Re: deciding between ruby and python * Gavin Sinclair [0447 18:47]: > On Monday, April 5, 2004, 12:09:58 AM, Yukihiro wrote: > > Maybe "join" should call "to_str" instead of "to_s" in the future. > Bad idea, IMO. "join" is designed for returning a string. It > therefore has the right to create strings as necessary for this > purpose. > "join" is similar to "puts" in this regard. Yeah, but it should be the objects decision whether it's able to provide a meaningful String version of itself. I generally use to_s for debugging, or any situation when I need to quickly 'see' the object - i.e. to_s provides a string representation of itself for *my* benefit. So 99% of my classes have a to_s method, but it's typically a list of its instance variables, for the very reason that puts calls it. join or anything else that wants a string to work with should ask the object to provide one, and to_str is there for that. If I haven't implemented that method I'm saying "I'm not a String, and I'm not going to pretend to be one". > And to consider another angle: join is a generally useful method. > #to_str is only implemented in a small set of classes. "join" would > become a lot less useful if you implemented that change. I still reckon join should be meeting those classes halfway. it's not their job to keep join happy at the end of the day. Classes who want to can easily 'alias_method :to_str :to_s', but only if *they* decide that makes sense in their case. -- A witty saying proves nothing, but saying something pointless gets people's attention. Rasputin :: Jack of All Trades - Master of Nuns