Hi Levente,

On Sun, Sep 06, 2020 at 02:19:21PM +0200, Levente Uzonyi wrote:
> Hi Dave,
> 
> On Sat, 5 Sep 2020, David T. Lewis wrote:
> 
> >
> >I moved Chronology-Core-dtl.56 to the treated inbox, and put
> >Chronology-Core-dtl.58 in the inbox to address the #oneDay issue.
> 
> Duration class >> #zero is similar to #oneDay in the sense that it's a 
> single instance in Squeak. It would be worth keeping it that way, as 
> existing users use it quite liberally.
> 
> Now that we support read-only objects, I think these shared objects should 
> be made read-only as well (#beReadOnlyObject). Something like this:
> 
> Duration class >> #initialize
> 
> 	"Duration oneDay is used in Date creation, and is cached to allow 
> 	sharing the instance."
> 	(OneDay := self days: 1) beReadOnlyObject.
> 	"Duration zero is used in various comparisons and computations, and 
> 	is cached to allow reusing the instance."
> 	(Zero := self seconds: 0 nanoSeconds: 0) beReadOnlyObject.
> 	"The following recompilation is only needed during the transition 
> 	from pool variables to class variables."
> 	self class
> 		recompile: #oneDay;
> 		recompile: #zero
> 

Yes, that is better. I put Chronology-Core-dtl.59 in the inbox to
add this, and moved Chronology-Core-dtl.58 to treated.

To your earlier point about Time having too many responsibilities already,
the secondsInDay, secondsInHour, and secondsInMinute methods are trivial
and have no functional value other than to document intent in methods that
send them. I wonder if it might be better to just get rid of them and add
a few comments in the appropriate methods.

Of course that contradicts my stated interest in having better compatibility
with Cuis, so maybe I am just running in circles here (as you previously
suggested with a smiley).

Dave