On 5/16/07, Metz, Bobby <[EMAIL PROTECTED]> wrote:
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 the event object to access the event details.
All event objects could have a "recurring event" property and the
required extra parameters defining the recurrence. Any action on an
object marked as a "recurring event" would kick off special routines to
populate the extra event object references in the "scheduling" list or
update those references if an event object is changed, deleted, or say
converted to a standalone event.
Just my 2 cents,
Bobby
Bobby brings up a point. If you go back a couple of threads where was
a dissagreement about an event containing the multiple time
information and putting multiple events (or, trivially, one event)
into a list, you can come up with two maps.
Let's look at the latter first
DateTime::Event - who what where added, time inherited from DateTime
DateTime::Schedule contains one or more events.
If you try the former:
DateTime::Event - who what where added, time inherited from DateTime,
list of DateTime added as DateTime::Schedule if a recurrning event
it doens't seem to fit. Heck, it doesn't even READ correctly to me.
-----Original Message-----
From: Dave Rolsky [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 16, 2007 2:04 PM
To: datetime
Subject: Re: DateTime::Event again
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 class or the
other,
>> not both.
>
> Hmm, I disagree. 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. A recurring event is a single entity -
> it is one thing and should only be stored one time.
I think you're mixing together the end-user view of an event and the
program API view.
Clearly, when one is programming a calendar system, recurring and single
events would have to have some different properties.
> Using your description, a one-off event could be described as a
> structured group containing only one event.
That's not a bad idea.
A better distinction might be between a recurring event (every Tuesday
at
noon) and a specific instance of that recurring event (May 15 at noon).
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
--
Matthew O. Persico