<div dir="ltr"><div dir="ltr">Hi Levente,</div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> 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,<br>
> 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.<br>
<br>
You may as well store the posix microseconds and recreate the <br>
DateAndTime instance with #utcMicroseconds:offset:.<br>
To get the clock value, you can either use <br>
#primPosixMicrosecondClockWithOffset: directly</blockquote><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> or you can use primitive <br>
240 and subtract the offset yourself.<br></blockquote><div><br></div><div>That's all what this does.  Brings two parts of the API into compatible use with each other...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
That way you can avoid introducing a new API </blockquote><div><br></div><div><div>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...</div><div></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">serving only a very specific <br>
goal.<br></blockquote><div><br></div><div>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..</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The VM clock is not monotonic, so you may want to use Time class >> <br>
#posixMicrosecondClockWithOffset: to get monotonic values.<br></blockquote><div><br></div><div>I don't actually need monotonicity here.  I really just want efficiency.  I thought you, of all, would appreciate that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Because of the above and because of the non-descriptive names, -1 from me <br>
for #fromMicroseconds: and #asMicroseconds.<br>
<br>
Also -1 for #microsecondClock. That would be the third (actually fourth <br>
but one was a typo) name for that primitive, and I'm bored migrating code <br>
from one to another because someone didn't like some part of the selector.<br></blockquote><div><br></div><div>:)  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...  :)</div><div><br></div><div>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:?</div><div><span style="background-color:rgb(255,255,255);font-family:Arial,Helvetica,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;color:rgb(34,34,34);display:inline!important;float:none"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> 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,<br>
> 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.<br>
<br>
The utc prefix tells me about the time zone offset. Its use is clear; <br>
removing it would introduce amiguity.<br>
<br>
Dave's "new" implementation uses the posix epoch. I'm surprised people <br>
who took part in its discussion 4-5 years ago seem to not be aware of <br>
that.<br></blockquote><div><br></div><div>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.</div><div><br></div><div> - Chris</div><div><br></div></div></div>