I have to get this off my chest.  Is anyone proud of this smorgasbord of
various clock values available in our, uh, "API".

  Time class>>#eventMillisecondClock
  Time class>>#highResClock
  Time class>>#localMicrosecondClockPrimitive
  Time class>>#localMicrosecondClockWithOffset
  Time class>>#millisecondClockValue
  Time class>>#posixMicrosecondClockWithOffset
  Time class>>#posixMicrosecondClockWithOffset:
  Time class>>#primPosixMicrosecondClockWithOffset
  Time class>>#primPosixMicrosecondClockWithOffset:
  Time class>>#totalSeconds
  Time class>>#utcMicrosecondClock
   DateAndTime class>>#millisecondClockValue  (same as Time
class>>#millisecondClockValue)
   DateAndTime class>>#totalSeconds   (same as Time class>>#totalSeconds)

It's already embarrassing to present to a new Smalltalk-80 user, but it can
actually add *injury* [2] to unsuspecting users who were trusting enough to
think that Squeak's API is a deliberate, crafted API.  For all its
technical capability and verbosity, there's still no elegant way for a
Smalltalk-80 user to simply, and *efficiently,* access the underlying
microsecond precision of the VM for use in the object environment.
*Nothing* we have for this is user-friendly in the slightest.

Last April I submitted a minor improvement to this situation to the
Inbox[1].  A completely beautiful and elegant, Smalltalk-80'ish addition of
just two methods, #asMicroseconds and #fromMicroseconds: for users to have
as a high-res complement to #asSeconds and #fromSeconds:, with comments
that were written to and for the *user* audience, and not the VM-developer
audience.

Sadly, but not really surprisingly, such user catering was handily
rejected.  I couldn't even finish addressing the first protester's
"alternative suggestions" -- none of which acknowledged my core requirement
(above) -- before someone else jumped in with their own "-1" on these
grounds:

    *"There is no need to add to the API. You already have Smalltalk
seconds at any level of precision care to use."*

He was talking about requiring the user to introduce inefficient Fractions
and/or ScaledDecimals into their domain, despite my having already
explained the requirement not to create unnecessary garbage or complexity.
Mind-bogglingly, this was from the same person who revamped and distilled
the whole of Chronology's DateAndTime down to the efficiency of just two
scalar values.

So, to this day, in spite of its sprawling family methods, Squeak's class
library, still, remains inadequate and needlessly stunted.  Power available
in the VM untapped, efficiency of the design, thwarted.

Over the following weeks[3[4] I submitted multiple alternatives based on
the feedback (all accommodating degradations that, again, failed to
recognize the core requirement (argh!)), such as, *only eliminating the
vicious trap*.  But, after countless hours having addressed every random
concern you could never imagine, my final submission[4] was basically left
to die on the doorstep, with nothing more than a rude comment from someone
who never really participated in the discussion at all.

It was after this episode that I more or less stopped participating in
trunk development.
________
Fast-forward to today.  Three days have passed since Eliot popped these two
new, but duplicate, methods right into the trunk.  No discussion.  Code so
fresh, not even the spell-checker had finished.  Two useless methods with
comments addressed to a VM developer audience.  Already a "+1," (post
trunk, lol) from a fellow VM-developer, and none of the former objections
leveled against my submissions seem important anymore, I guess.  But, users
are still out in the cold.

Trygve was right.

 - Chris

[1]
http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-April/208991.html
[2]
http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-May/209033.html
      (DateAndTime utcMicroseconds: Time utcMicrosecondClock offset: 0)
"looks reasonable, but it's VERY NOT!"
[3]
http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-May/209035.html
[4]
http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-May/209107.html

https://www.youtube.com/watch?v=fODt3iBXNv4

On Tue, Oct 6, 2020 at 12:19 AM <commits at source.squeak.org> wrote:

> Eliot Miranda uploaded a new version of Chronology-Core to project The
> Trunk:
> http://source.squeak.org/trunk/Chronology-Core-eem.61.mcz
>
> ==================== Summary ====================
>
> Name: Chronology-Core-eem.61
> Author: eem
> Time: 5 October 2020, 10:19:35.996376 pm
> UUID: 13de44be-afb9-4f0f-81b1-5f3f8fa821db
> Ancestors: Chronology-Core-dtl.60
>
> Provide Time class>>millisecondClock and DateAndTime
> class>>millisecondClock to indicate that this is now a proiper clock.  It
> will not roll-over after 45 days like the old 30 bit millisecond clock.
>
> Nw code should use millisecondClock, not millisecondClockValue, and old
> code (senders of millisecondClockValue) should be migrated whenever
> convenient.
>
> =============== Diff against Chronology-Core-dtl.60 ===============
>
> Item was added:
> + ----- Method: DateAndTime class>>millisecondClock (in category
> 'smalltalk-80') -----
> + millisecondClock
> +
> +       ^self clock millisecondClock!
>
> Item was added:
> + ----- Method: Time class>>millisecondClock (in category 'general
> inquiries') -----
> + millisecondClock
> +       "Answer the value of the millisecond clock. Unlike older
> implementatins, this is a clock; it will never roll-over."
> +
> +       ^self utcMicrosecondClock // 1000!
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201009/df7d4d48/attachment.html>