On Apr 23, 2010, at 10:25 PM, Henrik Johansen wrote: > It's still wrong though, in that it is not symmetric... > > Due to the isKindOf: self class test, and > = not being reimplemented in Timestamp (DateAndTime subclass), so Timestamp > to DateAndTime comparitions will fail: > > aDateandTime = anEquivalentTimestamp true > anEquivalentTimestamp = aDateAndTime false > > There's a test for you! :D
:) Stef > > Cheers, > Henry > > On Apr 23, 2010, at 10:01 30PM, Stéphane Ducasse wrote: > >> Thanks >> >> Chris about the speed what do you compare? >> using accessors to access month/date or something else. >> This is not clear to me. >> >> On Apr 23, 2010, at 9:49 PM, Chris Muller wrote: >> >>> In case anyone cares, Brent and I have been working together >>> professionally for the last couple of years. Brent, we have been >>> running with that method modified since 2007 to not do that >>> conversion. We have not sufferred any ill-effects from it. Check our >>> vanilla image: >>> >>> DateAndTime>>#= comparand >>> "comparand conforms to protocol DateAndTime, >>> or can be converted into something that conforms." >>> | comparandAsDateAndTime | >>> self == comparand ifTrue: [ ^ true ]. >>> (comparand isKindOf: self class) ifFalse: [ ^ false ]. >>> [ comparandAsDateAndTime := comparand asDateAndTime ] >>> on: MessageNotUnderstood >>> do: [ ^ false ]. >>> ^ self offset = comparandAsDateAndTime offset >>> ifTrue: [ self hasEqualTicks: comparandAsDateAndTime ] >>> ifFalse: [ self asUTC ticks = comparandAsDateAndTime asUTC >>> ticks ] >>> >>> I agree with Stef on this. Not only is it confusing to me, it is >>> inconsistent with other type-checks. But the primary reason I >>> overrode it back in 2007 was for better performance. Try benching the >>> above against the stock comparison... >>> >>> - Chris >>> >>> On Fri, Apr 23, 2010 at 2:26 PM, Brent Pinkney <br...@zamail.co.za> wrote: >>>> On Friday 23 April 2010 21:12:03 Stéphane Ducasse wrote: >>>>> Hi all >>>>> >>>>> I'm trying to fix some tests and I do not like the behavior of DateAndTime >>>>> = Comparing aDateAndTime and a something tries to convert the something in >>>>> a dateAndTime automagically. I find that not really good because it hides >>>>> potential problem: manipulating string instead of objects. >>>>> >>>>> So I would like to have >>>>> (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00' -> >>>>> false (aDateAndTime offset: '0:12:00:00') asString = >>>>> '1901-01-01T00:00:00+12:00' -> true. >>>>> >>>>> What do you think. >>>> >>>> Hi, >>>> >>>> I wrote that code, and it is needed to compare DateAndTimes with Timespans >>>> - eg Month, Year, Date... >>>> Please tread carefully - lots of production code relies on that. >>>> >>>> Already my (DateAndTime now != DateAndTime now) have been removed :( >>>> >>>> Thanks >>>> >>>> Brent >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project@lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
