On Tuesday, January 14, 2003, at 03:26 PM, Dave Rolsky wrote:
Erm, then there's been some kind of miscommunication, because that's not what I was trying to say...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().
My point was simply that for some other calendars, it may be sufficient to support them via a parse/format interface, rather than having a full-fledged DateTime object.
Yup, to my mind it's all one type of process, stringification, and you choose one of the available algorithms based on the specific purpose or kind of string you want.That's an odd point of view ;)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.
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."Hmm. I guess my phrasing would be "I need to get this date as a string in ICal format," but I'm not sure that English word order really provides a solid basis for making this decision.
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.Looking at the expression $dt->as_string('ICal'), the name of the format seems to me to stand out nicely.
Regardless, the fact that parsing/formatting is implemented as a collection of "strategy" classes doesn't prevent us from presenting a different kind of public interface if desired.
If you feel people need an $dt->as_ical_string() method so they don't need to call $dt->as_string('ICal'), I won't object.
-Simon
