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.


> 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...


> 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...


> 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..

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.


> 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:?

> 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.

 - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200430/9fd9ec9d/attachment-0001.html>