At a high level, recurring and single events don't have to have
different properties IMO, depending on how you structure the series of
event references. If you separate the event information from the
"scheduling", having an array, hash, whatever of scheduled events would
simply hold references to
On Wed, 16 May 2007, Simon Wistow wrote:
On Wed, May 16, 2007 at 04:46:56PM +0100, Zefram said:
A "recurring event" is not a single event. It is a structured group of
events. You should have distinct classes for single event and recurrence.
Most of the methods you list are applicable to one c
On 5/16/07, Simon Wistow <[EMAIL PROTECTED]> wrote:
I've started sketching out DateTime::Event - a module that would
represent a single, err, event.
It's based on my experiences with the Palm Calendar, Google Calendar and
the iCalendar standard.
Eventually it's my hope that there'd would be num
Simon Wistow wrote:
> In every calendaring system I've come across a
>recurring event and a single event are represented as the same thing
>only with different properties.
Bad OO design is very common. Especially, I have found, where dates
and times are concerned.
>
On Wed, May 16, 2007 at 04:46:56PM +0100, Zefram said:
> A "recurring event" is not a single event. It is a structured group of
> events. You should have distinct classes for single event and recurrence.
> Most of the methods you list are applicable to one class or the other,
> not both.
Hmm, I
Simon Wistow wrote:
>I've started sketching out DateTime::Event - a module that would
>represent a single, err, event.
...
>The problem we have here is that for one off events start and end are
>definite points in time. For recurring events this merely represents the
>earliest and latest instanc
I've started sketching out DateTime::Event - a module that would
represent a single, err, event.
It's based on my experiences with the Palm Calendar, Google Calendar and
the iCalendar standard.
Eventually it's my hope that there'd would be numerous implementations
of DateTime::Event::Provider
