From: Martin Duerst Date: 2008-01-25T17:47:41+09:00 Subject: Re: [PATCH] Friendlier methods to compare two Time objects At 11:38 08/01/25, Jim Cropcho wrote: >Does anyone think that it is a good idea to include similar methods for japanese/east asian languages? I don't think so. Ruby doesn't localize it's method names. If things are clear in simple English (as they are in your case), it should be fine. Regards, Martin. >I'm not too familiar with japanese/localization in ruby-core. Would that go in the same module, or a different one? > >Any naming scheme that helps visualize is good. How can we make this work best for the great number of locales? > >2008/1/24 Jim Cropcho <jim.cropcho@gmail.com >: >>Here is the newest patch. It creates a module called Temporal which contains functionality useful to classes which define temporal objects, such as dates and times. However, its intended scope is *not* limited to object comparison. It is handy in this regard, though, because it addresses differences between languages, as several in this thread have noted. >> >>The module is added to the compilation configuration, and unit tests are included, all of which pass. The module is included in the classes Time and Date (and DateTime, via extension). >> >>The module does not include the methods past? and present?, as intended, because the means of determining "now" is different even at the conceptual level between temporal classes. For example, "now" to Time is the number of microseconds after epoch, but "now" to Date is the current calendar date. It is my opinion that past?/future? functionality should be implemented at the class level. >> >>Please give my concept and source code consideration for being entered into the ruby core, and suggest modifications/additions at will. >> >> >>Jim Cropcho >> >>2008/1/23 Jim Cropcho < jim.cropcho@gmail.com>: >> >>>A new thought: >>> >>>> The way that the <=> method is rewritten for Time, it is >>>> optimized (as far as I can tell) to evaluate conditions >>>> based on nanoseconds only when equality cannot be >>>> determined via seconds. I may be misreading that. >>>> >>>> Conversely, Time inherits its > and < methods from its superclass, >>>> so surely those optimizations in <=> do not exist, and creating >>>> aliases would yield less-optimized code. Also, in the other classes >>>> where I add this functionality, current techniques to optimize >>>> comparisons will be reimplemented using the local methodology. >>> >>>from the rdoc for compar.c: >>> >>>The Comparable mixin is used by classes whose objects may be ordered. The class must define the <=> operator, which compares the receiver against another object, returning -1, 0, or +1 depending on whether the receiver is less than, equal to, or greater than the other object. Comparable uses <=> to implement the conventional comparison operators (<, <=, ==, >=, and >) and the method between?. >>> >>>I am now writing a Mixin called Temporal which will be included in the Time , Date and DateTime classes, and will contain the instance methods >>> >>>*before?(some_time) >>>*after?(some_time) >>>*future?(time = Time.now) >>>*past?(time = Time.now) >>> >>>I have the tests written and skeleton code to compile and include the module where necessary. I hope to be finished tomorrow. >>> >>>2008/1/23 Mathieu Blondel < mblondel@rubyforge.org >: >>>>Hi, >>>> >>>>2008/1/23, Martin Duerst < duerst@it.aoyama.ac.jp>: >>>> >>>>> There is even some cultural dependency here. In Japanese, for example, >>>>> the past is higher than the future, time flows down, >>>> >>>>And in Chinese as well. For example: >>>> >>>>下个星期 = next week, lit. below week >>>>上个星期 = last week, lit. above week >>>> >>>> >>>>Mathieu #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp