Hi Chris,

On Thu, 30 Apr 2020, Chris Muller wrote:

> Hi Levente,
>
>       > One of the main benefits of converting former Chronology's internal 3-element Array to an Integer should be to be able to easily translate back-and-forth between Integer and object (DateAndTime) representations.  With this,
>       > when creating log entries, you can simply access Time class>>#microsecondClock, which creates no garbage.  Then, to display the log, DateAndTime class>>#fromMicroseconds: will instantiate the proper instance of that time.
>
>       You may as well store the posix microseconds and recreate the
>       DateAndTime instance with #utcMicroseconds:offset:.
>       To get the clock value, you can either use
>       #primPosixMicrosecondClockWithOffset: directly
> 
> 
> As I mentioned to Dave, I wish to not create a bunch of unnecessary garbage.  Maybe you're suggesting I create my own two-pointer object only once and use it over and over, but I need thread safety.

It's fairly easy to achieve that with a process local variable.

>  
>       or you can use primitive
>       240 and subtract the offset yourself.
> 
> 
> That's all what this does.  Brings two parts of the API into compatible use with each other...

It brings two things closer together, but those two things are not as 
much related as you think.
And the way it does that causes problems for others.
If I were to do this, I just would add


Time class >> #posixUtcMicrosecondClock
 	"Answer the UTC microseconds since the POSIX epoch."

 	^self utcMicrosecondClock - MicrosecondsBetweenPosixEpochAndSqueakEpoch


and


ChronologyConstants class >> #initialize
 	"ChronologyConstants initialize"

 	...

 	MicrosecondsBetweenPosixEpochAndSqueakEpoch := 2177452800000000


Efficient, unambiguous, thread-safe.
To turn the number into a DateAndTime object, #utcMicroseconds:offset: 
is already there. (Yes, it would be better if that method had a 'posix' 
prefix.)

>  
>       That way you can avoid introducing a new API
> 
> 
> We already have #fromSeconds: and #asSeconds, so this is not really "new API", as much as rounding out existing API that just allows the domain to expose its underlying precision.  UTC DateAndTime's new internal representation was supposed to be one of its main selling points...

Just because there's existing bad API, we shouldn't add more, should we?

>  
>       serving only a very specific
>       goal.
> 
> 
> Efficient sub-second timings are not application-specific.  Look at all the new API added from Chronology-Core-nice.41 through Chronology-Core-nice.44 -- way more than this -- introduced to support high-precision clocks.  I don't recall you ever objecting to that..

I'm not against introducting new API. I'm against introducting bad API.

>
>       The VM clock is not monotonic, so you may want to use Time class >>
>       #posixMicrosecondClockWithOffset: to get monotonic values.
> 
> 
> I don't actually need monotonicity here.  I really just want efficiency.  I thought you, of all, would appreciate that.

I suppose my suggestion above is the best you can achieve in Smalltalk
in terms of efficiency.

>  
>       Because of the above and because of the non-descriptive names, -1 from me
>       for #fromMicroseconds: and #asMicroseconds.
>
>       Also -1 for #microsecondClock. That would be the third (actually fourth
>       but one was a typo) name for that primitive, and I'm bored migrating code
>       from one to another because someone didn't like some part of the selector.
> 
> 
> :)  Well, I don't want you to be bored, but I'm afraid that's not an argument.  You know how Squeak respects its users for upgrading their code.  This is only deprecated.  Check that box, you won't have to migrate anything.  But Squeak must continue to move forward...  :)
> 
> And it isn't about "not liking it" due to taste, but because it fosters a major disconnect in the reader due to the similar nomenclature used between Time and DateAndTime.  Seriously, you're okay with Time utcMicrosecondClock being so misleadingly (and, silently!) incompatible with DateAndTime
> utcMicroseconds:offset:?

It is unfortunate that
- #utcMicrosecondsClock is implemented as a class side method of Time, 
because it's unrelated to Time (renaming it to #microsecondsClock would 
not help with that)
- #utcMicroseconds:offset: is not called #posixUtcMicroseconds:offset:

>
>       > The "utc" prefix seems to be related to the name that Dave gave his alternative version of Chronology, and retained some of it when it was integrated into trunk.  I don't recall whether Time>>#utcMicrosecond was part of that,
>       > but if we can be willing to drop the prefix for that one selector, the API won't have this ambiguity that confused me for an evening.
>
>       The utc prefix tells me about the time zone offset. Its use is clear;
>       removing it would introduce amiguity.
>
>       Dave's "new" implementation uses the posix epoch. I'm surprised people
>       who took part in its discussion 4-5 years ago seem to not be aware of
>       that.
> 
> 
> A testament to how confusingly disjointed this particular part of the API is, Levente.  Please consider users' experience of when they read Squeak's API's the first time.  Smalltalk is supposed to be a "legendary" class library.  Chronology's API is fantastic, but this blemish stands out.  IMO, we should fix it.

Sorry, but I don't see it fantastic at all.


Levente

> 
>  - Chris
> 
> 
>