date and time port from squeak

Hello everyone.
I needed some nontrivial Date and Time behaviour, and I know it is not in
the ansi DateAndTime (which I had from Ian Bartholomew's goodie), so I took
a look at Squeak. What I found in Squeak 3.7 was a chronology package that
did pretty much everything I needed and much more, I was really impressed by
finding this complete time library for smalltalk.
So, I have to make a decision: should I add only what I need to Dolphin
using Squeak chronology only as a guide, or should I try to port chronology
to Dolphin ? I prefer the latter, but I think I'm not that much into Dolphin
yet as to know wheter the port is feasible and/or advisable, so I was hoping
someone could give me some advice.

The major problem I see to the port is changing Date and Time classes shape.
Nowadays, Dolphin Date looks like this:

Magniture
    Date (inst vars: days)

If I change exactly to Squeak chronology, it would look like this:

Magnitude
    Timespan (inst vars: start duration)
        Date

Normally, I would just change the class, but in this case, I have the
feeling that is a much more sensitive taks, because Date and Time classes
are so widely used, even by the system itself (it may be possible that if
something is wrong there, no image or package could be saved or load and
things like that).

These are the alternatives I can think of to deal with the shape problem:

- Make Date completely polimorphic with Timespan, but actually without
making it a subclass of Timespan nor changing its inst vars
With this approach, a Date object filed out _after_ the change could be read
by some clean Dolphin image, but I will have to mantain 2 sets of methods
almost identical (all the Timespan protocol)

- Make Date be a subclass of Timespan, increase its version number and write
a stbconvert method.
With this approach, a Date object filed out after the change could _not_ (I
think) be read by some clean Dolphin image, but I will have the exact same
model as in Squeak

Another issues I think I may find are precission and locale, but I don't
expect them to be as problematic as Date shape.

Is it worth the effort ?

Best regards.
Martin

> - Make Date completely polimorphic with Timespan, but actually without
> making it a subclass of Timespan nor changing its inst vars
> With this approach, a Date object filed out _after_ the change could be
> read
> by some clean Dolphin image, but I will have to mantain 2 sets of methods
> almost identical (all the Timespan protocol)

I think this is what I should do in your place, but that's only an opinion.

Allways think in your strategy in the best for the long run.

regards,


--
Sebastián Sastre
Seaswork
Special Software Solutions
www.seaswork.com.ar

Martin wrote:

> The major problem I see to the port is changing Date and Time classes
> shape.

Looking at the Squeak time stuff, it's quite an interesting approach.  From the
Date comment:

    Instances of Date are Timespans with duration of 1 day.

which is not an idea that would have occurred to me.  Taken at face value, I
think that means that a "Date" in Squeak is not the same kind of thing as a
"Date" in Dolphin -- they seem to be implementations of different concepts.  As
such (even without the technical "shape" problems) I'd be inclined to give it a
different name -- 'Day', or 'SqueakDate', perhaps.

I'd probably do the same thing with Time, while I was at it -- I suspect it
would be easier to port the Squeak stuff if you can get it working as a unit
without worrying about incompatibilities with the Dolphin version of Time.

    -- chris

> I think this is what I should do in your place, but that's only an
opinion.
>
> Allways think in your strategy in the best for the long run.

Yes, I think you and Chris have a point. I will start for the most simple,
less invasive and native dolphin compatible port. Then, if I need it, I will
see how to integrate it more with the ambient.

Thanks !

Regards.
Martin

> I'd probably do the same thing with Time, while I was at it -- I suspect
it
> would be easier to port the Squeak stuff if you can get it working as a
unit
> without worrying about incompatibilities with the Dolphin version of Time.

yes yes yes, of course !!!! I don't know why I haven't ever considered this
! I guess I just wanted so bad to plug the new classes instances into a Date
or Time presenter that I lost the path even before starting.
I will definitely port it first as a unit, and once I can see it working, I
will decide where to go from there.

Thanks !

regards.
martin