From: Kirk Haines <khaines@...>
Date: 2005-08-02T23:52:56+09:00
Subject: Re: (mis)?use of method_missing

On Tuesday 02 August 2005 6:56 am, Kero wrote:

> I don't. What does an Integer have to know about times and dates?

This is why I use it as an extension in specific cases.  :)  For me, sometimes 
convenience wins over principle.

> irb(main):001:0> 3 + Time.now
> TypeError: Time can't be coerced into Fixnum
>  from (irb):1:in `+'
>         from (irb):1
> irb(main):002:0> Time.now + 3
> => Tue Aug 02 14:20:43 CEST 2005

I can live with that.  The value in redefining + and - isn't worth the cost in 
that case.

> #  - need different constants in Time/Date, etc.
> #    but then, 3.days.from(Time.now) and 3.days.from(Date.today)
> #    is going to stink too, unless you introduce a Day or Duration class...

Why?  6.months.ago returns a Time.
Date.today.ago(6.months) returns a Date.

Is the objection that 3.days returns 259200?  I can see that on one level, 
because Date and DateTime work off of a different scale than Time, does. 
Adding 10 to a DateTime is entirely different than adding 10 to a Time.  But, 
really, adding 3.days to each should work the same (in my library, though, it 
currently does not).

> ### Advantages:
> #  - no 'readable' methods polluting Integer namespace.

True.  But, again, this is an extension to be used when it's pragmatic, and 
isn't intended to be part of the core.

> a = Time.now - 4*Days
>
> > irb(main):005:0> b = a.from_now(1.week)
> >=> Fri Aug 05 05:08:19 MDT 2005
>
> b = a + Week
> # I'm much shorter here and I don't have the confusing word "now" in the
> # code.

from_now is just an alias.  I could also do:

b = a + 1.week

And, in fact, when I use these, that's how I do it, most of the time.  Every 
once in a while, from_now _reads_ better to me, for a specific use, though, 
and since my goal is to make this code easy for _me_ to read and maintain, 
I'll use it in those cases.

> > irb(main):006:0> c = 2.weeks.since(b)
> >=> Fri Aug 19 05:08:19 MDT 2005
>
> c = b + 2*Week

That works if b is a Time.  With your constants, though, that fails if b is a 
Date or DateTime, as you alluded to in your Disadvantages list.

irb(main):003:0> b = DateTime.now
=> #<DateTime: 211989753587396153/86400000000,-1/4,2299161>
irb(main):004:0> 2.weeks.since(b).to_time
=> Tue Aug 16 08:39:47 MDT 2005

> please use "next" and "prev" (as well as "last" and "first" :P )
> in pairs.

In my English vernacular, last month is the previous month, but yeah, one can 
do:

a = Time.now.prev_month

> if anything, last_month should be a class method, like Time.now()

Maybe.  next_month and next_year and their ilk are just sugar to make the code 
read a bit more easily, for me.

One of the places where I use this is in a web based calendar that a customer 
uses to schedule her workshops and conferences.  It shows her a view of three 
months at a time, and for me it is convenient to just keep track of the 
middle month and then refer to the following or previous months with 
#next_month and #last_month.

Making next_month into a class method would be far less useful to me.


Thanks,

Kirk Haines