I have no problem if you want move Chronology classes to their own package (but please do use the "-Core" and "-Tests" suffixes so we don't suffer the prefix selection problem). I'll be curious whether you choose to move Date and Time too..
I'm a heavy user of Chronology, if there's a better version of it, I'm definitely interested in possibly using it. I remember that thread; it helped us identify and fix a performance bug in standard Chronology.
On Thu, Feb 18, 2016 at 11:30 AM, David T. Lewis lewis@mail.msen.com wrote:
I guess it has been nearly two years since I did that project. Time flies.
We discussed it on the list in thread "A UTC based implementation of DateAndTime":
http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-May/178325.html
But I'm not asking you to review that project, I just wanted to suggest giving Chronology its own package so that it would be possible to do things like this. For my purposes, I can always use a SAR. But it would be a lot nicer to be able to use Monticello.
Dave
I read it, it tells me _what_ it is; a different internal representation for the Chronology classes, but I could not put together the why, as a user, I should want to use it. This is not a criticism, Dave, just ignorance. What's are the pros and cons of UTCDateAndTime approach?
On Thu, Feb 18, 2016 at 10:51 AM, David T. Lewis lewis@mail.msen.com wrote:
Hi Chris,
This was something I did last year:
http://wiki.squeak.org/squeak/6197
I would like to be able to share this so folks can review the code. I'd prefer to be able to do that with Monticello, which is not practical with the current package structure.
Dave
On Wed, Feb 17, 2016 at 7:33 PM, David T. Lewis lewis@mail.msen.com wrote:
I would like to move Chronology from 'Kernel-Chronology' to a new package called 'Chronology', and move 'KernelTests-Chronology' to a new package called 'Tests-Chronology'.
Rationale:
- Chronology is a large package that is functionally separable from
the rest of the things in Kernel.
It's not that big. It includes Date and Time, which are part of base Smalltalk-80. How you going to extricate those from Chronology?
- I have a UTC based variation of Chronology that addresses a number
of issues that I think may be of long term benefit, and that prevent the kinds of issues that we are currently seeing in trunk. I would like to offer this for review in the inbox, but that is not practical with the current packaging.
Chronology has proved its usefulness in a wide variety of applications. I have no issues with it. What issues are you attempting to address with your UTC based variation?
Would anyone object to this change to package structure?
I really think Date and Time and possibly even DateAndTime are part of Kernel Smalltalk-80. I think it would be nice to know what it is you're really trying to accomplish with your UTC variation..
Incidentally, if you do go down this road, the standard that most packages following these days are hierarchical names; Chronology-Core and Chronology-Tests.