Re: Parsing/Formatting API

[Matthew Simon Cavalletto]

On Tuesday, January 14, 2003, at 02:33  PM, Dave Rolsky wrote:

On Tue, 14 Jan 2003, Matthew Simon Cavalletto wrote:

Modules like Date::Discordian or Date::Maya, which have no internal
storage format and only exist to convert to and from other calendar
formats, could easily be refactored to follow this interface.
  print $dt->to_string( strftime => $fmt );
  # Calls DateTime::Format::strtime::rdsec_to_string($rd, $sec, $fmt)
  print $dt->to_string( 'Discordian' );
  # Calls DateTime::Format::Discordian::rdsec_to_string($rd, $sec)

Hmmm, this isn't a bad idea.  But how is it much better than:

 my $disc = DateTime::Calendar::Discordian->new( ... );
 print DateTime->new( object => $disc )->strftime( ... );

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.

In practice, many of the foreign calendar modules are currently implemented as pairs of conversion functions, like Date::Maya's julian_to_maya and maya_to_julian or Locale::Hebrew::Calendar's g2j and j2g. I assume that it'd be much faster to turn those into DateTime::Formats than to make them full-featured DateTime objects.

We want something more like Strategies (ie, given several similar
algorithms, rather than having a bunch of different methods or a big
case statement, put each in its own class and call them as needed):

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.

I'm strongly inclined to treat parsing and formatting as the "same" thing (well, really, the opposite thing) because it seems likely that implementors of parsing for format X will also want to implement output in format X, and it'll be easier to put this in a single module if the implementation is done in the same manner.

Yes, definitely agreed.

-Simon