<div dir="ltr"><div dir="ltr">I have to get this off my chest. Is anyone proud of this smorgasbord of various clock values available in our, uh, "API".<div><br></div><div> Time class>>#eventMillisecondClock<br></div><div> Time class>>#highResClock</div><div></div><div> Time class>>#localMicrosecondClockPrimitive<br></div><div> Time class>>#localMicrosecondClockWithOffset<br></div><div> Time class>>#millisecondClockValue<br></div><div> Time class>>#posixMicrosecondClockWithOffset<br></div><div> Time class>>#posixMicrosecondClockWithOffset:<br></div><div> Time class>>#primPosixMicrosecondClockWithOffset<br></div><div> Time class>>#primPosixMicrosecondClockWithOffset:<br></div><div> Time class>>#totalSeconds</div><div><div> Time class>>#utcMicrosecondClock</div><div> DateAndTime class>>#millisecondClockValue (same as Time class>>#millisecondClockValue)<br></div><div> DateAndTime class>>#totalSeconds (same as Time class>>#totalSeconds)<br></div><div><br></div><div>It's already embarrassing to present to a new Smalltalk-80 user, but it can actually add <i>injury</i> [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 <u>efficiently,</u> access the underlying microsecond precision of the VM for use in the object environment. <u>Nothing</u> we have for this is user-friendly in the slightest.</div><div><br></div><div>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 <i>user</i> audience, and not the VM-developer audience.</div><div><br></div><div>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:</div><div><br></div><div> <i>"There is no need to add to the API. You already have Smalltalk seconds at any level of precision care to use."</i></div><div><br></div><div></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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, <i>only eliminating the vicious trap</i>. 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.</div><div><br></div><div><div>It was after this episode that I more or less stopped participating in trunk development.</div><div></div></div><div>________</div><div>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.</div></div><div><br></div><div>Trygve was right.<br></div><div><br></div><div> - Chris</div><div><br></div><div>[1] <a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-April/208991.html" target="_blank">http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-April/208991.html</a></div><div>[2] <a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-May/209033.html" target="_blank">http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-May/209033.html</a></div><div> (DateAndTime utcMicroseconds: Time utcMicrosecondClock offset: 0) "looks reasonable, but it's VERY NOT!"</div><div>[3] <a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-May/209035.html" target="_blank">http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-May/209035.html</a></div><div>[4] <a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-May/209107.html" target="_blank">http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-May/209107.html</a></div><div><br></div><div></div><div><a href="https://www.youtube.com/watch?v=fODt3iBXNv4" target="_blank">https://www.youtube.com/watch?v=fODt3iBXNv4</a><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 6, 2020 at 12:19 AM <<a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Eliot Miranda uploaded a new version of Chronology-Core to project The Trunk:<br>
<a href="http://source.squeak.org/trunk/Chronology-Core-eem.61.mcz" rel="noreferrer" target="_blank">http://source.squeak.org/trunk/Chronology-Core-eem.61.mcz</a><br>
<br>
==================== Summary ====================<br>
<br>
Name: Chronology-Core-eem.61<br>
Author: eem<br>
Time: 5 October 2020, 10:19:35.996376 pm<br>
UUID: 13de44be-afb9-4f0f-81b1-5f3f8fa821db<br>
Ancestors: Chronology-Core-dtl.60<br>
<br>
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.<br>
<br>
Nw code should use millisecondClock, not millisecondClockValue, and old code (senders of millisecondClockValue) should be migrated whenever convenient.<br>
<br>
=============== Diff against Chronology-Core-dtl.60 ===============<br>
<br>
Item was added:<br>
+ ----- Method: DateAndTime class>>millisecondClock (in category 'smalltalk-80') -----<br>
+ millisecondClock<br>
+ <br>
+ ^self clock millisecondClock!<br>
<br>
Item was added:<br>
+ ----- Method: Time class>>millisecondClock (in category 'general inquiries') -----<br>
+ millisecondClock<br>
+ "Answer the value of the millisecond clock. Unlike older implementatins, this is a clock; it will never roll-over."<br>
+ <br>
+ ^self utcMicrosecondClock // 1000!<br>
<br>
<br>
</blockquote></div>
</div>