Hi --

On Mon, 28 May 2007, Erwin Abbott wrote:

> On 5/28/07, Stefan Rusterholz <apeiros / gmx.net> wrote:
>> Universal Date/Time comparison is indeed difficult as neither your nor
>> mine (below) solution attribute for different TimeZones and/or DST.
>> I'd implement a universal comparison like below:
>> 
>> def <=>(other)
>>   [year, day_of_year, hour, minute, second] <=> [other.year,
>> other.day_of_year, other.hour, other.minute, other.second]
>> end
>
> I was just trying to illustrate the need for using case to determine
> an object's class.  If we were to use mixins as an alternative, it's
> still very complicated because we'll need to redefine Time#<=>,
> Date#<=> and so on. Won't we now have to check if
> other.is_a?(DateComp) and still handle the cases when
> other.is_a?(self.class)... ? I don't see any difference, because now
> we're relying on knowing about DateComp instead of Time or Date.

You don't have to test for DateComp ancestry, though.  You just assume
it (or equivalent) in your method, and then make sure that only
objects with that mixin (or equivalent) are passed to the method.
That way, you encapsulate just the operation itself in the method
(basically, duck typing), and the caller takes responsibility for only
sending along objects that fit the bill.  (Ha ha, bill, duck, get it?
Oh, never mind :-)


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)