[ruby-talk:7760] Re: Code sample for improvement

On Wed, 20 Dec 2000, Guy N. Hurst wrote:

> David Alan Black wrote:
> > 
> > Your approach is a great way to
> > translate seconds into an English representation of time since
> > 1/1/1970.  But I think there are legitimate reasons that one might
> > interpret the seconds-to-English task differently. 
> 
> You have a good point here; I did not really think it mattered, since
> he already accepted an inaccurate 30 day/month standard. (But then the
> trick I used in the algorithm also has an issue, as you aptly pointed out.)

Actually the seconds-per-thing figures in Steve W.'s original table, I
now see, are weighted to reflect leap years, unequal months, etc.
(For instance, fed to your to_time, Steve's year is "1 year 6 hours 3
mins 36 secs".)  Some other versions used the integral
60/60/24... ratios, though those could be tweaked, I guess, to
distribute the unevenness more widely.

> > (By the way, I'm not specifically defending my own version of this
> > -- I have nothing riding on that, nor any conviction that it
> > couldn't be improved upon.)

> I believe you. I think you were having fun.  And I did leave it
> open that what I discovered could be improved upon also; I just
> think it was better so far, for what was asked.  I almost didn't put
> that part in there, but I really felt that way.  Wouldn't you agree
> that, since functions are not first class objects in Ruby, that it
> makes more sense to focus on the objects?  I think this is what
> Steve was getting at (Steve?).  To do this it seems that I should
> minimize parameters and put the methods inside appropriate classes
> with a carefully selected name.

Yes, although it would be pretty easy to do something like:

   class Time
     def Time.table
       [ [ 31557816, 'year'        ],
       [    2629818, 'month'       ],

       [ ... ]
     end
   end

   class String
     def tfactor
       result = ""
       time = to_i
       Time.table.each do |secs_per, thing, plur|
       [...]
     end
   end

Admittedly I didn't actually do that :-)  But it's not precluded.

(Hmmm.... class Time... that gives me an idea....  Or maybe it just
reminds me that I'm supposed to be grading papers....)

> So, perhaps this is a conversation *starter* ?  :-)
>
> Yeah, it is probably safer to just say you can do things as you like,
> but in fact, I hear plenty of people wondering if there is a specific
> ideal way of doing things in Ruby, and if so, what is it? Sometimes
> it may really be a toss-up. But not always. Not in this case, either.
> It is ideal to be able to make a method that belongs to the object's class.

In case it's unclear: I didn't mean that any way of implementing
something is as good as any other way.  My point was, rather, that we
may be talking about two or more different "somethings".  (I can't
help thinking: "There May Be More Than One 'It' To Do" :-)  Once one
determines which thing one is doing, *then* the question of
idiomatic/efficient/Ruby-like Ruby comes into play.  

Then again, there may be a meta-Ruby-ness which should guide one
through implementing anything.  But at the level, for example, of
deciding whether to use a lookup table or the built-in method names to
designate minutes, seconds, etc....  it would be possible to argue for
either (the table is more internationalizable, etc.) and still not
have advocated anything totally un-Ruby-like.  But that doesn't mean
that there wouldn't be good and bad ways to implement the table
lookup.  (I'm not sure that you actually meant that the table per se
was unidiomatic... but anyway, you see my main distinction.)


David

-- 
David Alan Black
home: [e-mail]
work: [e-mail]
Web:  http://pirate.shu.edu/~blackdav