TimeStamp Redundant? Should we Remove/Deprecate it? (was Re: [squeak-dev] TimeSpan and DateAndTime? Date is a TimeSpan with a duration of 1 day? aka TimeStampTest>>#testAccessing failure)

Levente Uzonyi leves at elte.hu
Thu Sep 16 21:33:41 UTC 2010


On Thu, 16 Sep 2010, Ken Causey wrote:

> Hi Chris,
>
> I have to admit it had not really occurred to me to consider TimeStamp
> redundant and a candidate for removal, although I can see your point.
> It appears from the thread you link to that it is marked for removal
> from Pharo and possibly has been given this discussion was from April.
>
> I did in fact implement what I discussed below so all Chronology tests
> pass now and that is in Trunk.
>
> I haven't yet checked the image to see if TimeStamp is used internally,
> but assuming it is not (and even if it is that can be fixed without too
> much trouble I expect) then the question becomes if anyone is relying on
> it externally.
>
> Users of TimeStamp, consider this a call for your comments regarding the
> possibility of removing or at least deprecating TimeStamp in Squeak for
> 4.2.

I think it would be nice to get rid of TimeStamp. The instance side 
methods are only used by the tests in the image (and those don't seem 
to be really useful anyway), but the class side methods have a few 
users. Obviously the users also reference the class itself. Notable users 
are Monticello and SqueakMap. Those may break if Timestamp is removed. 
Someone with enough time/knowledge should check how the Timestamp objects 
are handled by these packages. I can imagine that SqueakMap serializes 
instances of it and will try to load them back later.
IMHO the class should be deprecated in 4.2 (I wonder if we have tools for this 
besides moving it to a package like 42Deprecated).


Levente

>
> Ken
>
> On Thu, 2010-09-16 at 13:03 -0500, Chris Muller wrote:
>> Hi Ken.  Brent Pinkney, the author of Chronology, agrees that
>> TimeStamp is redundant and should be removed.
>>
>>   http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg25308.html
>>
>> Since you just did some work on it, I won't remove it myself, but if
>> you want remove it and the test, I support that.
>>
>>  - Chris
>>
>>
>> On Fri, Sep 10, 2010 at 6:31 PM, Ken Causey <ken at kencausey.com> wrote:
>>> I haven't been Squeaking much for a while but for some reason I got the
>>> urge to exercise and break off a little rust so I thought I would look
>>> at a few failing tests in Trunk and see if I could address one or two.
>>> I've had a little success (barring personal misunderstanding) with a
>>> couple in the last two days but I ran into TimeStampTest>>#testAccessing
>>> and learned about a whole new level of 'not understanding'.
>>>
>>> The test itself seems simple enough; compare the date and time parts of
>>> a prepared TimeStamp value to 'literal' values that should be
>>> equivalent.  The test fails and weirdly enough because the result of
>>> String>>#asDate and TimeStamp>>date are both Dates but the Dates hold
>>> instances of different classes as their start values (more on this in a
>>> moment); DateAndTime and TimeStamp respectively.
>>>
>>> So this brings up the question: Why do we have both DateAndTime and
>>> TimeStamp?  The class comments on both are effectively identical, in
>>> fact TimeStamp is a subclass of DateAndTime and defines a few accessor
>>> methods but no additional instance variables.  I suspect the reason is
>>> historical, that one is a Squeak-ism and another is per ANSI Smalltalk.
>>>
>>> The problem occurs in the definition of DateAndTime>>#asDate which is
>>> simply "^ Date starting: self" and Date class>>#starting: simply assumes
>>> it's argument is a DateAndTime and stores a reference to it as passed.
>>> TimeStamp does not redefine #asDate and as such the result of sending
>>> #asDate to a TimeStamp instance is a date referencing a TimeStamp as
>>> it's start value.  Other conversions to Date will have DateAndTime
>>> instances as their start values.
>>>
>>> So I can see 2 solutions to this, I feel that in fact both should be
>>> implemented.
>>>
>>> 1.  TimeStamp should define #asDate converting itself to a DateAndTime
>>> in the process.
>>>
>>> 2.  a TimeStamp and DateAndTime referencing equivalent instances in time
>>> should be equivalent.
>>>
>>> Minor rant: Does it really makes sense that a Date is a TimeSpan with a
>>> fixed 1 day length?
>>>
>>> Thoughts?
>>>
>>> Ken
>>>
>>>
>>>
>>
>>
>
>



More information about the Squeak-dev mailing list