April 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] about DateAndTime =

by StÃ©phane Ducasse

I'm turning this into tests! Brent if you want to help fixing let me know. I will focus now on the parsing problem. Stef On Apr 23, 2010, at 9:51 PM, Nicolas Cellier wrote: > 2010/4/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> 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. >> > > I would expect this for = > 1) Reflexive > self assert: x = x. > 2) Symmetric > self assert: (x = y) = (y = x). > 3) Transitive > self assert: (x = y) & (y = z) ==> (x = z). > > I guess equality with a String at least breaks 2). > > Nicolas > > >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by StÃ©phane Ducasse

+1 Stef On Apr 23, 2010, at 9:51 PM, Nicolas Cellier wrote: > 2010/4/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> 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. >> > > I would expect this for = > 1) Reflexive > self assert: x = x. > 2) Symmetric > self assert: (x = y) = (y = x). > 3) Transitive > self assert: (x = y) & (y = z) ==> (x = z). > > I guess equality with a String at least breaks 2). > > Nicolas > > >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by StÃ©phane Ducasse

in Pharo1.0 = comparand "comparand conforms to protocol DateAndTime, or can be converted into something that conforms." | comparandAsDateAndTime | self == comparand ifTrue: [ ^ true ]. ----> this one is absent: (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 ] Now I would love to understand what is slower than that :) > > Hi, Chris Muller has just told me that I am dead wron on the equality issue, so I stand corrected. He will post soon. > > On the above, this is a bit of archeology - the Month and Week classes were introduced into Squeak before I added the ANSI > Chronology classes and the whole Timespan hierarchy. > > I could only get the chronology into the image by preserving compatibility. > > It could probably be refactored now. Please send us some code because this would be good to have it straight now. :) > > Brent > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by StÃ©phane Ducasse

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 <brent(a)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(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by StÃ©phane Ducasse

Now I'm more fighting with (Duration readFrom: '0:00:00:00.001 ' readStream) nanoSeconds -> 1 http://code.google.com/p/pharo/issues/detail?id=1202 as well as self assert: (DateAndTime readFrom: '1901-01-01T00:00:00+12:00' readStream) asString -> '1901-01-01T00:00:00+02:00' ;) which works in squeak! Stef On Apr 23, 2010, at 9:37 PM, Henrik Johansen wrote: > > On Apr 23, 2010, at 9:26 31PM, Brent Pinkney 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 > Because even if the resolution of a DateAndTime is nanoseconds, the clock available to derive now from has a resolution of milliseconds (microseconds using an updated VM on some platforms). (Not to mention the now method actually uses a second resolution...) > > Thus a test which states that asking for now two times in a row should always result in different DateAndTime values does not make sense. > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by StÃ©phane Ducasse

Thanks for the explanation. Stef On Apr 23, 2010, at 9:37 PM, Henrik Johansen wrote: > > On Apr 23, 2010, at 9:26 31PM, Brent Pinkney 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 > Because even if the resolution of a DateAndTime is nanoseconds, the clock available to derive now from has a resolution of milliseconds (microseconds using an updated VM on some platforms). (Not to mention the now method actually uses a second resolution...) > > Thus a test which states that asking for now two times in a row should always result in different DateAndTime values does not make sense. > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by Nicolas Cellier

2010/4/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > 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. > I would expect this for = 1) Reflexive self assert: x = x. 2) Symmetric self assert: (x = y) = (y = x). 3) Transitive self assert: (x = y) & (y = z) ==> (x = z). I guess equality with a String at least breaks 2). Nicolas > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by Brent Pinkney

> Do you have examples? For month I have problems, > Then I wonder why > > aDateAndTime = aMonth > is better > than > aDateAndTime month = aMonth Hi, Chris Muller has just told me that I am dead wron on the equality issue, so I stand corrected. He will post soon. On the above, this is a bit of archeology - the Month and Week classes were introduced into Squeak before I added the ANSI Chronology classes and the whole Timespan hierarchy. I could only get the chronology into the image by preserving compatibility. It could probably be refactored now. Brent

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by Chris Muller

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 <brent(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by StÃ©phane Ducasse

Hi brent >> > Hi, > > I wrote that code, and it is needed to compare DateAndTimes with Timespans - eg Month, Year, Date... Do you have examples? For month I have problems, Then I wonder why aDateAndTime = aMonth is better than aDateAndTime month = aMonth > Please tread carefully - lots of production code relies on that. did you mean that production code rely on string automatic conversion when compared to? > > Already my (DateAndTime now != DateAndTime now) have been removed :( Apparently it was not in 3.9 so I do not know when it was removed but this was not in pharo. Then finally if you do not raise the issue we are not omniscient so we cannot know it. stef > > Thanks > > Brent > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 23, 2010