Franciso,

Thanks for your feedback!

Francisco: "For someone that just needs dates and times, I found that
Chronos is somewhat bigger than needed."

Chronos is intended as an industrial strength date/time library that "covers
the space" and meets or exceeds the functionality provided by the
competition.  That that will be more than what many people need (or think
they need) is a foregone conclusion. There are many classes/packages in
Squeak (and also in VisualWorks) which provide far more functionality than I
need (and in many cases, I have no need of the function at all.)

Not everyone needs a station wagon, a truck or an SUV.  Some wouldn't
consider anything less than a Lambourghini, and others can only afford a
Yugo.

The good news is that Moore's Law is relentlessly reducing the relative
"cost" of a fixed amount of memory, and Craig and others are working on
better modularization mechanisms and technologies to mitigate (or even
eliminate) the monolithic image problem.

Then there's Java, which provides a lot less than what I need :-)

Over time I am sure I will find ways to put Chronos on a diet, and to
modularize it so that it's not a monolithic "all or nothing" choice.  It's
definitely an issue on my "to do" list.

First make it run, then make it right, then make it fast, then refactor, ...

Francisco: "suffering from overgrown objects in my every day job, makes me
suspicious..."

Understood.  Don't think I didn't consider the matter.  In fact, I was
expecting someone to voice this concern eventually.

There are three cases:

1) The instance variables hold "computed values" for performance reasons.
In my considerable experience, having many such instance variables is not
indicative of a design or architectural flaw--provided they actually enhance
performance, and provided there isn't a much better implementation where
they wouldn't be needed.  Obviously, I'd love to discover a better
implementation where instance variables could be removed without sacrificing
performance.

2) The instance variables hold policy decisions (this especially applies to
ChronosParser and ConfigurableChronosPrintPolicy.) Each policy decision
requires a slot to hold it.

The design issue is simply whether storing such policy decisions is well
motivated.  I believe the answer is yes in all cases.

The whole point to the design strategy of ConfigurableChronosPrintPolicy
(for example) was to provide a single class whose functionality could be
specified and controlled by configurable state, as opposed to requiring a
maze of subclasses.  Flexible, configurable printing of date/time values
requires many different, independent policy decisions.

The architectural issue is whether or not it would be better to refactor
ConfigurableChronosPrintPolicy (for example) into a set of classes, each
responsible for a subset of the functionality of the original class. My
opinion is that the added code complexity (and added conceptual complexity)
would not be worth the "brownie points" of having fewer instance variables.
Nor do I see any benefit to be gained by having a DatePrintPolicy class, a
TimePrintPolicy class, a DurationPrintPolicy class, etc. The behavior does
not need to vary independently--partly because the variation in behavior is
in fact a function of the instance variable values, and not so much a
function of the instance methods. And the multiple-class approach adds
classes without actually eliminating the universe of instance variables
(although it disperses some of the instance variables among the classes,
most of the same instance variables would still all need to be together in
an abstract superclass.)

3) In the cases of ResourcePathContext and
TimeZoneAnnualTransitionPolicyFactory, there are 10 or fewer instance
variables--and points 1 and/or 2 often apply as well.

Note also that almost all Chronos classes inherit from Immutable, which
defines the single instance variable "lock."  This instance variable serves
as a flag to indicate whether the instance is mutable, and so deserves to be
considered (and counted) as a metalevel construct separate from the "base
level" instance variables of its subclasses.

Note also that it is not at all likely (and in some cases unbelievable) that
there would be all that many instances of most of the classes you mentioned.
There should only be one instance of each Calendar class, for example. Even
TimeZoneAnnualTransitionPolicyFactory should never need more than a thousand
instances, and more typically there should only be 1 or 2 at any one time.

"Architecture is not inflexible dogma."

--Alan

-----Original Message-----
From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of
Francisco Garau
Sent: Tuesday, April 18, 2006 11:57 PM
To: The general-purpose Squeak developers list
Subject: Re: The Timing of Time

Alan said:
 "In fact, I would greatly appreciate feedback on the
design/implementation/API of Chronos"

For someone that just needs dates and times, I found that Chronos is
somewhat bigger than needed.

>From the implementation point of view, I found that the Calendar object
>is
quite fat (lots of instance variables). This might not be a problem at all,
but suffering from overgrown objects in my every day job, makes me
suspicious...

Calendar is not the only object with many instance variables. There are
severeal others: LeapSecond, ChronosParser, ConfigurableChronosPrintPolicy,
LeapSecondSchedule, TimeZoneAnnualTransitionPolicyFactory,
ResourcePathContext.

More detail in the attached files: ChronosCalendar shows the printString of
the a calendar and ChronosHierarchy shows the whole class hierarchy
(assuming all the Chronos classes inherit from StandarObject).

But please, don't be offended by this feedback - after all, you asked for
it!

As Ralph Jonhson said, we need to keep discussing this issues. And as you
said, we need keep improving our models - otherwise, everything is lost in
the sea of words.

Cheers,
Francisco

PD: I like your poetic nature. The title of this thread is irresistible

----- Original Message -----
From: "Alan Lovejoy" <squeak-dev.sourcery at forum-mail.net>
To: "'The general-purpose Squeak developers list'"
<squeak-dev at lists.squeakfoundation.org>
Sent: Wednesday, April 19, 2006 2:51 AM
Subject: RE: The Timing of Time


> Ralph: "Date is a basic abstraction.  Getting it right is important, and
> so
> far we (the entire programming community) haven't gotten it right."
>
> Yes, exactly so. And the issue is becoming more important, not less, due
> to
> the ever-shrinking "global village."  How many decades remain before the
> issues become interplanetery, and not just international, is an
> interesting
> question to ponder (I've considered the implications of interplanetary
> travel for date/time software, but haven't put much effort or code into
> any
> solutions yet--that might be premature at this point.)
>
> When all is said and done, it's usually the case that a lot more has been
> said than done.  That's one reason I implemented Chronos according to my
> best understanding of how dates/times ought to work, instead of attempting
> to socialize a consensus in the Smalltalk community for the design of a
> date/time library.  A picture of herding cats comes to mind. Or a camel.
>
> Nevertheless, one can always learn from others.  In fact, I would greatly
> appreciate feedback on the design/implementation/API of Chronos.  I'm sure
> that Hernan, Brent and David T. would like feedback on their work also.
>
> Ralph: "You guys ought to write papers on your Date packages. Someone
> ought
> to write a paper comparing them."
>
> Ayup.  In fact, I've decided to put a halt to coding Chronos and start
> writing documentation.  John Dougan and I started to write a paper several
> months ago about the model of time on which the Chronos architecture,
> design
> and implementation rests, but we both got sidetracked on/by other matters.
>
> It's "time" to put the theoretical/philosophical discussion back on the
> front burner. As for comparisons of the alternatives on offer, that's a
> job
> best left to some independent analyst, I would think.
>
> --Alan
>
> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of Ralph
> Johnson
> Sent: Tuesday, April 18, 2006 5:38 PM
> To: The general-purpose Squeak developers list
> Subject: Re: The Timing of Time
>
> It is interesting to me 1) how much interest there is in dates and 2) how
> apologetic people seem to be about it.  Date is a basic abstraction.
> Getting it right is important, and so far we (the entire programming
> community) haven't gotten it right.  Discussions like this are important.
> You guys ought to write papers on your Date packages.
> Someone ought to write a paper comparing them.
>
> Maybe Maxi Taborda is going to do this for his MS thesis?
>
> My favorite book on calenders (I haven't read very many) is "Calendrical
> Calculations" by Reingold and Dershowitz.  It is about dates and not time.
>
> -Ralph Johnson
>
>
>