From: Gavin Sinclair Date: 2004-04-05T15:23:48+09:00 Subject: Re: deciding between ruby and python On Monday, April 5, 2004, 3:09:19 PM, Dave wrote: > In article <1081124063.259819.9185.nullmailer@picachu.netlab.jp>, Yukihiro Matsumoto wrote: >> Hi, >> >> In message "Re: deciding between ruby and python" >> on 04/04/05, Guillaume Marcais writes: >> >>|Just a as we are on the subject. Should Ojbect#to_s return self.to_str >>|if it is defined instead of the default value? >> >> I encourage defining "to_str" along with string methods, i.e. by >> defining "to_str", I expect the object to be a duck quacks like >> strings. In that sense, you have to think before defining "to_str", >> more than it seems, even though your proposal makes sense. > I'd really like to understand what you mean, here. In your first sentence, > did you mean to say "I expect the object to be a duck *that* quacks like > strings?" If so, what does it mean to quack like a string? If not, what were > you really trying to say? I won't speak on Matz's behalf, but it's important to remember that when you call #to_str, then you are getting back a string. That sounds obvious, but all this talk of duck typing might confuse someone into believing that you can influence the original object after you've called #to_str on it! When a class implements #to_str, it should be careful to return a new object (e.g. use #dup) so that the caller can't damage the object itself. # The problem we have understanding to_str is that it slipped into # Ruby (I think) between 1.6 and 1.8, and it's not treated in any # books that I know of. Gavin