On Tue, 14 Jan 2003, Matthew Simon Cavalletto wrote: > OK, that'll let us parse a Discordian date and format it as a > Gregorian; I assume that to print something in Discordian format we'd > use: > > my $disc = DateTime::Calendar::Discordian->new( object => $dt ); > print $disc->strftime( ... ) > > I'm concerned that this approach may end up requiring that > DateTime::Calendar::Discordian to be a subclass of DateTime, and I know > you've recently argued that calendars that aren't Gregorian shouldn't > be subclasses of DateTime due to API confusion issues.
You seem to be assuming that other calendars are likely to be able to take advantage of DateTime.pm methods like strftime() or hour(). I am assuming that this won't be the case. But I'm not a calendar author. Rich, Abigail, Jean? What do you think. If other calendars are likely to end up with APIs similar to the Gregorian calendar, then having strftime in a separate module definitely makes sense. > > For formatting, strategies really don't make sense. Formatting isn't > > a question of different algorithms, it's a question of having > > functionality A and/or B. > > Hmm; I understand what you're saying, but from the point of view of the > design pattern, the algorithm I'm talking about is "express a date/time > as a written text string", and each of the formatting functions is a > different way of accomplishing that task. That's an odd point of view ;) What you are saying is that different datetime formats are different ways of doing _the same thing_, with a different underlying algorithm. In effect, you seem be saying that its about converting a datetime object to a string, with the resulting string being just a detail of the algorithm at hand. But of course, nobody things about this like that. The thought process is not "I need to convert this object to a string. Now I must select a format. I select ICal." Instead, people think "I need to tell this date to display itself as an ICal string" or "I need to get this date as an ICal string." The first statement is just a slightly formalized rewording of the second. The _format_ to be represented is the item of interest, not the object to string conversion. So the API needs to focus on the format, not the act of conversion. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
