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. > A recurring event is a single entity - Yes, sure it is. It's worthy of being represented by a specific type of object. It's just that that's not the same type as a single event. >it is one thing and should only be stored one time. I did not intend otherwise. It is certainly useful (and essential in infinite cases) to represent a recurrence just as a single object, not reifying each occasion. Reifying a particular instance (as an event object) should be done only when attention turns to the particular. When the particular *is* interesting, though, one certainly does want an object referring to that instance and not to all the other occasions of recurrence. That's what your "recurrences" method is about. >Using your description, a one-off event could be described as a >structured group containing only one event. You could certainly have such a trivial recurrence. It's about as useful as a one-element array. >A recurring event can and will have all the same characteristics of a >single event It does not have a specific start time, which is possibly the most fundamental aspect of a single event. Treatment of characteristics such as attendees, which you listed, depends on your model of recurrence, but you indicated a model in which a recurrence has just default values: quite different semantics from the definitive values of a single event. But most of your characteristics have only trivial semantics in the event object context anyway: bad things to base your class hierarchy design on. >It might be that a RecurrentEvent could be a subclass of SingleEvent. That would indicate that a recurrent event is a single event, which is not true. >vice versa, That's closer to the mark, treating single events as trivial recurrences. It's like treating a character as a string of length one. Perl does the latter, but in general I think it's a bad strategy. > or both are subclasses of a GenericEvent object, Tricky to say what a GenericEvent actually represents in that case. >more of an implementation detail rather than a conceptual detail. On the contrary, it is of the most profound conceptual importance. -zefram
