From: Marc-Andre Lafortune Date: 2009-06-09T00:49:58+09:00 Subject: [ruby-core:23756] Re: [Bug #1583] Time + String no Longer Raises TypeError? I'd like to second long explicit names. Maybe it's because I'm not coming from perl, but there are already maybe abreviations that I find questionable (elsif, Array#uniq, Time#min). Let's remember that "str" and "int" are usual abbreviations (which you'll find on wikipedia, for instance), while flo, rat, etc... are not. I also like Eero's suggestion. On Mon, Jun 8, 2009 at 4:35 AM, "Martin J. D�rst" wrote: > On 2009/06/08 0:27, Eero Saynatkari wrote: >> >> Excerpts from Yukihiro Matsumoto's message of Sun Jun 07 17:07:06 +0300 >> 2009: >>> >>> Hi, >>> >>> In message "Re: [ruby-core:23743] [Bug #1583] Time + String no Longer >>> Raises >>> TypeError?" >>> � � on Sun, 7 Jun 2009 13:00:26 +0900, Akira >>> Tanaka �writes: >>> >>> |I like to_rat. >>> >>> #to_rat alone? �Or along with to_flo, to_comp, to_dec, etc? >> >> Since some of these names will inevitably turn out to be >> somewhat hard to decode at first glance, might it be an >> option to consider establishing a convention different >> from the #to_i => �#to_int style and make it #to_i and >> #as_i (or #to_int and #as_int) instead? >> >> #to_ �produces a representation of object, as #to_s. >> #as_ �"converts" object to type, as #to_str. > > Another opinion would be to use somewhat longer names where three letters > isn't helpful. When I saw to_rat first, I was first thinking of a little > rodent. #to_rational isn't that long, for the number of times it needs to be > used, I guess. > > Regards, � Martin. > >> In my opinion, the symmetry would be helpful and the two >> different prefixes help separate their responsibilities? >> Of course, it is a departure from past semi-convention. >> >> >> Regards, >> � � � � Eero >> >> -- >> Magic is insufficiently advanced technology. >> >> >> > > -- > #-# Martin J. D�rst, Professor, Aoyama Gakuin University > #-# http://www.sw.it.aoyama.ac.jp � mailto:duerst@it.aoyama.ac.jp > >